home *** CD-ROM | disk | FTP | other *** search
/ The 640 MEG Shareware Studio 2 / The 640 Meg Shareware Studio CD-ROM Volume II (Data Express)(1993).ISO / os2 / redbk2.zip / GG243731.INF (.txt)
OS/2 Help File  |  1992-09-28  |  842KB  |  13,462 lines
  1.  
  2. ΓòÉΓòÉΓòÉ 1. (C) Copyright IBM Corp. 1992 ΓòÉΓòÉΓòÉ
  3.  
  4. (C) Copyright International Business Machines Corporation 1992. All rights 
  5. reserved. 
  6.  
  7. Note to U.S. Government Users - Documentation related to restricted rights - 
  8. Use, duplication or disclosure is subject to restrictions set forth in GSA ADP 
  9. Schedule Contract with IBM Corp. 
  10.  
  11.  
  12. ΓòÉΓòÉΓòÉ 2. Cover ΓòÉΓòÉΓòÉ
  13.  
  14.  
  15. ΓòÉΓòÉΓòÉ <hidden> Title Page ΓòÉΓòÉΓòÉ
  16.  
  17.  
  18.                                                                 OS/2 Version 2.0
  19.                                                        Volume 2: Dos and Windows
  20.                                                                      Environment
  21.  
  22.                                                     Document Number GG24-3731-00
  23.  
  24.                                                                       April 1992
  25.  
  26.  
  27.                                                          International Technical
  28.                                                                   Support Center
  29.  
  30.                                                                       Boca Raton
  31.  
  32.  
  33. ΓòÉΓòÉΓòÉ 3. Version Notice ΓòÉΓòÉΓòÉ
  34.  
  35. Take Note:  Before using this information and the product it supports, be sure 
  36.             to read the general information under Special Notices. 
  37.  
  38. First Edition (April 1992) 
  39.  
  40. This edition applies to OS/2 Version 2.0. 
  41.  
  42. Order publications through your IBM representative or the IBM branch office 
  43. serving your locality. Publications are not stocked at the address given below. 
  44.  
  45. A form for reader's comments appears at the back of this publication. If the 
  46. form has been removed, address your comments to: 
  47.  
  48. IBM Corporation, International Technical Support Center
  49. Dept. 91J, Building 235-2 Internal Zip 4423
  50. 901 NW 51st Street
  51. Boca Raton, Florida 33432 USA
  52.  
  53. When you send information to IBM, you grant IBM a non-exclusive right to use or 
  54. distribute the information in any way it believes appropriate without incurring 
  55. any obligation to you. 
  56.  
  57. MAK - Revision 1.0
  58.  
  59.  
  60. ΓòÉΓòÉΓòÉ 4. Abstract ΓòÉΓòÉΓòÉ
  61.  
  62. This document describes both the Multiple Virtual DOS Machines (MVDM) component 
  63. of OS/2 Version 2.0 and the implementation of Microsoft Windows application 
  64. support under OS/2 Version 2.0.  It forms Volume 2 of a five volume set; the 
  65. other volumes are: 
  66.  
  67.  OS/2 Version 2.0 - Volume 1:  Control Program GG24-3730 
  68.  
  69.  OS/2 Version 2.0 - Volume 3:  Presentation Manager and Workplace Shell 
  70.   GG24-3732 
  71.  
  72.  OS/2 Version 2.0 - Volume 4:  Application Development GG24-3774 
  73.  
  74.  OS/2 Version 2.0 - Volume 5:  Print Subsystem GG24-3775 
  75.  
  76. The entire set may be ordered as OS/2 Version 2.0 Technical Compendium, 
  77. GBOF-2254. 
  78.  
  79. This publication is intended for IBM customers, IBM system engineers,  and IBM 
  80. authorized dealers, and other individuals who require a knowledge of the 
  81. features, functions, and implementation of DOS and Microsoft Windows 
  82. application support under OS/2 Version 2.0. 
  83.  
  84. This document assumes that the reader is generally familiar with the DOS 
  85. operating system and Microsoft Windows, and with the function provided in 
  86. previous releases of OS/2. 
  87.  
  88.  
  89. ΓòÉΓòÉΓòÉ 5. Acknowledgements ΓòÉΓòÉΓòÉ
  90.  
  91. The project leader and editor for this project was: 
  92.  
  93. Hans J. Goetz
  94. International Technical Support Center, Boca Raton
  95.  
  96. The authors of this document are: 
  97.  
  98. Robert Beck
  99. IBM United Kingdom
  100.  
  101. Herman Benders
  102. IBM Netherlands
  103.  
  104. Bo Falkenberg
  105. IBM Denmark
  106.  
  107. Dorle Hecker
  108. IBM Germany
  109.  
  110. Patrick Lee
  111. IBM Australia
  112.  
  113. Robert Penrose
  114. IBM Canada
  115.  
  116. Dwight Ronquest
  117. ISM South Africa
  118.  
  119. Laurie Rose
  120. IBM UK
  121.  
  122. Karl-Peter Schweder
  123. IBM Germany
  124.  
  125. Tim Sennitt
  126. IBM UK
  127.  
  128. Neil Stokes
  129. IBM Australia
  130.  
  131. Bernd Westphal
  132. IBM Germany
  133.  
  134. This publication is the result of a series of residencies conducted at the 
  135. International Technical Support Center, Boca Raton. 
  136.  
  137. This document was converted to the Information Presentation Facility by: 
  138.  
  139. Michael Kaply
  140. IBM Development Laboratories, Austin.
  141.  
  142. Thanks to the following people for the invaluable advice and guidance provided 
  143. in the production of this document: 
  144.  
  145. Terri Beck
  146. IBM Programming Center, Boca Raton.
  147.  
  148. Sam Casto and his staff
  149. IBM Programming Center, Boca Raton.
  150.  
  151. Monte Copeland
  152. IBM Programming Center, Boca Raton.
  153.  
  154. Mark Fiechtner
  155. IBM Programming Center, Boca Raton.
  156.  
  157. George Fulk
  158. IBM Programming Center, Boca Raton.
  159.  
  160. Alfredo Guti╨Ærrez
  161. IBM EMEA Education Center, Boca Raton.
  162.  
  163. Kip Harris
  164. IBM Programming Center, Boca Raton.
  165.  
  166. David Kerr
  167. IBM Programming Center, Boca Raton.
  168.  
  169. Bill Madden
  170. IBM Programming Center, Boca Raton.
  171.  
  172. Martin McElroy
  173. IBM European Personal Systems Center, Basingstoke.
  174.  
  175. Jeff Muir
  176. IBM Programming Center, Boca Raton.
  177.  
  178. Frank Schroeder
  179. IBM Programming Center, Boca Raton.
  180.  
  181. Jerry Stegenga
  182. International Technical Support Center, Boca Raton.
  183.  
  184. John Tyler
  185. IBM Programming Center, Boca Raton.
  186.  
  187. David Young
  188. IBM Western Area Systems Center, Los Angeles.
  189.  
  190. Thanks also to the many people, both within and outside IBM, who provided 
  191. suggestions and guidance, and who reviewed this document prior to publication. 
  192.  
  193. Thanks to the following people for providing excellent tools, used during 
  194. production of this document: 
  195.  
  196. Dave Hock (CUA Draw)
  197. IBM Cary.
  198.  
  199. J╨ærg von K╨önel (PM Camera)
  200. IBM Yorktown Heights.
  201.  
  202. Georg Haschek (BM2IPF)
  203. IBM Austria.
  204.  
  205.  
  206. ΓòÉΓòÉΓòÉ 6. Figures ΓòÉΓòÉΓòÉ
  207.  
  208.  Concurrent DOS Applications under the Workplace Shell 
  209.  MVDM Architecture 
  210.  MVDM System Structure Overview 
  211.  MVDM System Structure and Control Flow 
  212.  MVDM Protected Mode processes 
  213.  VDM Exception Handling 
  214.  Typical VDM Address Space Map 
  215.  VDM Initialization 
  216.  Virtual Display Management 
  217.  Virtual Keyboard Management 
  218.  Virtual Mouse Management 
  219.  VDM Exceptions and Interrupt Handling in a V86 Mode Task 
  220.  Descriptor Privilege Levels 
  221.  A20 Line Service (64KB Wraparound) 
  222.  V86 Memory Map Prior to DOS Emulation Initialization 
  223.  V86 Memory Map at Initial V86 Mode Entry 
  224.  V86 Memory Map after Initialization 
  225.  Default AUTOEXEC.BAT File 
  226.  Physical and Virtual Device Drivers under OS/2 Version 2.0 
  227.  Structure of Bi-Modal Device Drivers in OS/2 V1.x 
  228.  Physical Device Driver Statements in CONFIG.SYS 
  229.  Virtual Device Driver Statements in CONFIG.SYS 
  230.  Virtual COM and Physical COM Device Drivers 
  231.  Virtual Printer Device Driver Operation 
  232.  Virtual Programmable Interrupt Controller 
  233.  General Overview of Different Types of Memory for DOS Applications 
  234.  Expanded Memory Manager Control Flow 
  235.  Memory Map of Areas Supported by Extended Memory 
  236.  Extended Memory Manager Control Flow 
  237.  CONFIG.SYS - Loading Device Drivers into UMBs 
  238.  LOADHIGH Command - Loading TSRs into UMBs 
  239.  The Migrate Applications Windows 
  240.  DBTAGS.DAT 
  241.  User Definitions for other Applications 
  242.  Windows Applications Running under OS/2 Version 2.0 
  243.  Single Windows Application Running under OS/2 Version 2.0 
  244.  Single Windows Application(s) Running "Seamless" on the OS/2 Version 2.0 
  245.   Desktop 
  246.  Implementation of "Seamless" WIN-OS/2 VDM in OS/2 Version 2.0 
  247.  Installing Windows Support under OS/2 Version 2.0 
  248.  Defining a Windows Application to OS/2 Version 2.0 
  249.  Migrating the Windows Initialization Files 
  250.  p.Detailed View of the WIN-OS/2 Data Connections 
  251.  Low Level View of the WIN-OS/2 Printing Data Flow 
  252.  File Structure of Adobe Type Manager 
  253.  OS/2 Version 2.0 Clipboard Environment 
  254.  DDE Process between Windows Environments 
  255.  DDE Process between Presentation Manager and Windows 
  256.  Client/Server Structure for Operating System Extenders 
  257.  The Program Page of the Settings Notebook 
  258.  The Session Page of the Settings Notebook 
  259.  The DOS Settings Dialog of the Settings Notebook 
  260.  Setting Up a TSR Program 
  261.  The DOS Settings Dialog of the Settings Notebook 
  262.  The Program Page of the Settings Notebook for a VMB 
  263.  DOS Settings - DOS_STARTUP_DRIVE 
  264.  VMB from an OS/2 V2.0 Program 
  265.  Personal Communications/3270 for Windows running under OS/2 V2.0 
  266.  Memory Map of Extended Memory (HMA, UMA, and EMBs) 
  267.  QENV.BAT Batch File 
  268.  C Source Code for ENVIRON.EXE 
  269.  INT19.BAS Source Code 
  270.  GRAPHIC.BAS Source Code 
  271.  
  272.  
  273. ΓòÉΓòÉΓòÉ 6.1. Concurrent DOS Applications under the Workplace Shell ΓòÉΓòÉΓòÉ
  274.  
  275. We apologize for the picture quality.  The original was not available. 
  276.  
  277.  
  278. ΓòÉΓòÉΓòÉ 6.2. MVDM Architecture ΓòÉΓòÉΓòÉ
  279.  
  280.  
  281. ΓòÉΓòÉΓòÉ 6.3. MVDM System Structure Overview ΓòÉΓòÉΓòÉ
  282.  
  283.  
  284. ΓòÉΓòÉΓòÉ 6.4. MVDM System Structure and Control Flow ΓòÉΓòÉΓòÉ
  285.  
  286.  
  287. ΓòÉΓòÉΓòÉ 6.5. MVDM Protected Mode processes ΓòÉΓòÉΓòÉ
  288.  
  289.  
  290. ΓòÉΓòÉΓòÉ 6.6. VDM Exception Handling ΓòÉΓòÉΓòÉ
  291.  
  292.  
  293. ΓòÉΓòÉΓòÉ 6.7. Typical VDM Address Space Map ΓòÉΓòÉΓòÉ
  294.  
  295.  
  296. ΓòÉΓòÉΓòÉ 6.8. VDM Initialization ΓòÉΓòÉΓòÉ
  297.  
  298.  
  299. ΓòÉΓòÉΓòÉ 6.9. Virtual Display Management ΓòÉΓòÉΓòÉ
  300.  
  301.  
  302. ΓòÉΓòÉΓòÉ 6.10. Virtual Keyboard Management ΓòÉΓòÉΓòÉ
  303.  
  304.  
  305. ΓòÉΓòÉΓòÉ 6.11. Virtual Mouse Management ΓòÉΓòÉΓòÉ
  306.  
  307.  
  308. ΓòÉΓòÉΓòÉ 6.12. VDM Exceptions and Interrupt Handling in a V86 Mode Task ΓòÉΓòÉΓòÉ
  309.  
  310.  
  311. ΓòÉΓòÉΓòÉ 6.13. Descriptor Privilege Levels ΓòÉΓòÉΓòÉ
  312.  
  313.  
  314. ΓòÉΓòÉΓòÉ 6.14. A20 Line Service (64KB Wraparound) ΓòÉΓòÉΓòÉ
  315.  
  316.  
  317. ΓòÉΓòÉΓòÉ 6.15. V86 Memory Map Prior to DOS Emulation Initialization ΓòÉΓòÉΓòÉ
  318.  
  319.  
  320. ΓòÉΓòÉΓòÉ 6.16. V86 Memory Map at Initial V86 Mode Entry ΓòÉΓòÉΓòÉ
  321.  
  322. This diagram shows the VDM's memory map when the V86 mode DOS Emulation kernel 
  323. is first invoked. 
  324.  
  325.  
  326. ΓòÉΓòÉΓòÉ 6.17. V86 Memory Map after Initialization ΓòÉΓòÉΓòÉ
  327.  
  328. This diagram shows the VDM's memory map after initialization of the DOS 
  329. environment and prior to loading a DOS application. 
  330.  
  331.  
  332. ΓòÉΓòÉΓòÉ 6.18. Default AUTOEXEC.BAT File ΓòÉΓòÉΓòÉ
  333.  
  334. PATH C:\OS2;C:\OS2\MDOS;C:\;
  335. LOADHIGH APPEND C:\OS2;C:\OS2\SYSTEM
  336. PROMPT $I$P$G
  337.  
  338.  
  339. ΓòÉΓòÉΓòÉ 6.19. Physical and Virtual Device Drivers under OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  340.  
  341. This example shows the asynchronous communications port. 
  342.  
  343.  
  344. ΓòÉΓòÉΓòÉ 6.20. Structure of Bi-Modal Device Drivers in OS/2 V1.x ΓòÉΓòÉΓòÉ
  345.  
  346.  
  347. ΓòÉΓòÉΓòÉ 6.21. Physical Device Driver Statements in CONFIG.SYS ΓòÉΓòÉΓòÉ
  348.  
  349. DEVICE=C:\OS2\MOUSE.SYS TYPE=PDIMOU$            (Mouse PDD)
  350. DEVICE=C:\OS2\COM.SYS                           (COM port PDD)
  351.  
  352.  
  353. ΓòÉΓòÉΓòÉ 6.22. Virtual Device Driver Statements in CONFIG.SYS ΓòÉΓòÉΓòÉ
  354.  
  355. DEVICE=C:\OS2\MDOS\VMOUSE.SYS                   (Mouse VDD)
  356. DEVICE=C:\OS2\MDOS\VCOM.SYS                     (COM port VDD)
  357. DEVICE=C:\OS2\MDOS\VEMM.SYS                     (EMS VDD)
  358.  
  359.  
  360. ΓòÉΓòÉΓòÉ 6.23. Virtual COM and Physical COM Device Drivers ΓòÉΓòÉΓòÉ
  361.  
  362.  
  363. ΓòÉΓòÉΓòÉ 6.24. Virtual Printer Device Driver Operation ΓòÉΓòÉΓòÉ
  364.  
  365.  
  366. ΓòÉΓòÉΓòÉ 6.25. Virtual Programmable Interrupt Controller ΓòÉΓòÉΓòÉ
  367.  
  368. Notes to the numbers in the above figure: 
  369.  
  370.  1.  8259 PIC port accesses 
  371.      VPIC initialization entry point (VDDInit) 
  372.      VPIC VDM creation entry point (vpicCreateVDM) 
  373.  
  374.  2.  Call when interrupts enabled service (VDHArmSTIHook) 
  375.      Return to VDM interrupt code service (VDHPushInt) 
  376.  
  377.  3.  Set the global and the VDM context hook service (VDHArmContextHook) 
  378.      Start the timer service (VDHArmTimerHook) 
  379.      Set the VDM priority service (VDHSetPriority) 
  380.  
  381.  4.  Set the IRET and EOI handlers service (VDHOpenVIRQ) 
  382.      Set the virtual IRR request service (VDHSetVIRR) 
  383.      Clear the virtual IRR request service (VDHClearVIRR) 
  384.      Get virtual IRQ status service (VDHQueryVIRQ) 
  385.      Send virtual EOI service (VDHSendEOI) 
  386.      Wait for simulated interrupt service (VDHWaitVIRRs) 
  387.      Wake up the VDM waiting for a simulated interrupt (VDHWakeVIRRs) 
  388.  
  389.  5.  Physical PIC hardware interrupt requests and EOI 
  390.      VPIC requests an IRQ level will be dispatched to VPIC if no physical 
  391.     device driver services the interrupt (INTSetVDMIRQ) 
  392.      VPIC notifies the interrupt manager of the end of the interrupt 
  393.     processing (INTEOIVDMIRQ) 
  394.  
  395.  6.  Hardware Interrupt dispatching 
  396.      The interrupt manager transfers control to the VPIC for hardware 
  397.     interrupts that the VPIC has set, and no physical device driver has 
  398.     serviced (VPICIntHdlr) 
  399.  
  400.  
  401. ΓòÉΓòÉΓòÉ 6.26. General Overview of Different Types of Memory for DOS Applications ΓòÉΓòÉΓòÉ
  402.  
  403.  
  404. ΓòÉΓòÉΓòÉ 6.27. Expanded Memory Manager Control Flow ΓòÉΓòÉΓòÉ
  405.  
  406.  
  407. ΓòÉΓòÉΓòÉ 6.28. Memory Map of Areas Supported by Extended Memory ΓòÉΓòÉΓòÉ
  408.  
  409.  
  410. ΓòÉΓòÉΓòÉ 6.29. Extended Memory Manager Control Flow ΓòÉΓòÉΓòÉ
  411.  
  412.  
  413. ΓòÉΓòÉΓòÉ 6.30. CONFIG.SYS - Loading Device Drivers into UMBs ΓòÉΓòÉΓòÉ
  414.  
  415. DEVICE = C:\OS2\VXMS.SYS
  416. DEVICEHIGH = SIZE = 1A00 C:\OS2\MDOS\ANSI.SYS
  417. DOS = UMB
  418.  
  419.  
  420. ΓòÉΓòÉΓòÉ 6.31. LOADHIGH Command - Loading TSRs into UMBs ΓòÉΓòÉΓòÉ
  421.  
  422. LOADHIGH progname <program parameters>
  423.  
  424.  
  425. ΓòÉΓòÉΓòÉ 6.32. The Migrate Applications Windows ΓòÉΓòÉΓòÉ
  426.  
  427.  
  428. ΓòÉΓòÉΓòÉ <hidden> DBTAGS.DAT ΓòÉΓòÉΓòÉ
  429.  
  430. //                           +--------------------+
  431. //                           | NOTE TO TRANSLATOR |
  432. //                           +--------------------+
  433. // Do not translate keywords or data types and delete these lines when done.
  434. // ============================================================================
  435. // dbtags.dat -- DOS setting "tags" used by PARSEDB and MIGRATE.  Each "tag"
  436. // consists of an index, a keyword, and a data type.
  437. //             +------------------------------------------------+
  438. //             | DO NOT EDIT THIS FILE UNDER ANY CIRCUMSTANCES! |
  439. //             +------------------------------------------------+
  440. // ============================================================================
  441. // Allows BASIC-style comments.
  442. // ----------------------------------------------------------------------------
  443. 1   REM                        NOP
  444.  
  445. // ----------------------------------------------------------------------------
  446. // Required "fake" DOS settings.
  447. // ----------------------------------------------------------------------------
  448. 2   NAME                       STR    // Filename used to execute application
  449. 3   TITLE                      STR    // Icon (desktop) title
  450. 4   TYPE                       BYTE   // Application type
  451.                                       // Valid settings: DOS
  452.                                       //                 Windows
  453.                                       //                 OS/2
  454.                                       //                 custom (for Microsoft
  455.                                       //                 Windows apps which
  456.                                       //                 must run full-screen)
  457. 5   ASSOC_FILE                 STR    // Associated file (NULL if one isn't
  458.                                       // known)
  459. 6   DEF_DIR                    STR    // Default installation directory (NULL
  460.                                       // if there isn't one)
  461.  
  462. // ----------------------------------------------------------------------------
  463. // Other "fake" DOS settings.
  464. // ----------------------------------------------------------------------------
  465. 7   FOLDER                     STR    // Name of folder to create and/or put
  466.                                       // the application icon in
  467. 8   PARAMETERS                 STR    // Application's command line parameters
  468. 9   WORK_DIR                   STR    // Application's working directory
  469.  
  470. // ----------------------------------------------------------------------------
  471. // "Fake" Windows settings
  472. // ----------------------------------------------------------------------------
  473. 10  WIN_FILES                  STR    // Files to be copied to the WinOS2
  474.                                       // directory when the application is
  475.                                       // migrated
  476. 11  COMMON_SESSION             BOOL   // Default: ON  -> the application is to
  477.                                       //                 be run in the common
  478.                                       //                 session
  479.                                       //          OFF -> the application is to
  480.                                       //                 be run "standalone"
  481.  
  482. // ----------------------------------------------------------------------------
  483. // Real DOS settings.  NOTE: WIN_RUNMODE is not supported; all Windows apps are
  484. // installed with SEAMLESS and WPS handles the mapping.
  485. // ----------------------------------------------------------------------------
  486. //  WIN_RUNMODE                INT    // Valid settings: 10 (REAL)
  487.                                       //                 11 (STANDARD)
  488.                                       //                 12 (AUTO)
  489.                                       //                 13 (SEAMLESS)
  490. 13  COM_HOLD                   BOOL   // Default: off
  491. 14  DOS_BREAK                  BOOL   // Default: off
  492. 15  DOS_DEVICE                 MLSTR  // Default: empty
  493. 16  DOS_FCBS                   INT    // Limits: 0 to 255, default 16
  494. 17  DOS_FCBS_KEEP              INT    // Limits: 0 to 255, default 8
  495. 18  DOS_FILES                  INT    // Limits: 20 to 255, default 20
  496. 19  DOS_HIGH                   BOOL   // Default: off
  497. 20  DOS_LASTDRIVE              STR    // Limits: last physical drive to 'Z',
  498.                                       //         default 'Z'
  499. 21  DOS_RMSIZE                 INT    // Limits: 128 to 640, default 640
  500.                                       // NOTE: increments of 16
  501. 22  DOS_SHELL                  STR    // Default: "#:\OS2\MDOS\COMMAND.COM "
  502.                                       //          "#:\OS2\MDOS\ /P" where #
  503.                                       //          is the boot drive
  504. 23  DOS_STARTUP_DRIVE          STR    // Default: empty
  505. 24  DOS_UMB                    BOOL   // Default: off
  506. 25  DOS_VERSION                MLSTR  // Default: DCJSS02.EXE,3,40,255
  507.                                       //          DFIA0MOD.SYS,3,40,255
  508.                                       //          DXMA0MOD.SYS,3,40,255
  509.                                       //          IBMCACHE.COM,3,40,255
  510.                                       //          IBMCACHE.SYS,3,40,255
  511.                                       //          ISAM.EXE,3,40,255
  512.                                       //          ISAM2.EXE,3,40,255
  513.                                       //          ISQL.EXE,3,40,255
  514.                                       //          NET3.COM,3,40,255
  515.                                       //          EXCEL.EXE,10,10,4
  516.                                       //          PSCPG.COM,3,40,255
  517.                                       //          SAF.EXE,3,40,255
  518.                                       //          WIN200.BIN,10,10,4
  519. 26  DPMI_DOS_API               STR    // Valid settings: AUTO (default)
  520.                                       //                 ENABLED
  521.                                       //                 DISABLED
  522. 27  DPMI_MEMORY_LIMIT          INT    // Limits: 0 to 512, default 3
  523. 28  EMS_FRAME_LOCATION         STR    // Valid settings: AUTO (default)
  524.                                       //                 NONE
  525.                                       //                 C000
  526.                                       //                 C400
  527.                                       //                 C800
  528.                                       //                 CC00
  529.                                       //                 D000
  530.                                       //                 D400
  531.                                       //                 D800
  532.                                       //                 DC00
  533.                                       //                 8000
  534.                                       //                 8400
  535.                                       //                 8800
  536.                                       //                 8C00
  537.                                       //                 9000
  538. 29  EMS_HIGH_OS_MAP_REGION     INT    // Limits: 0 to 96, default 32
  539.                                       // NOTE: increments of 16
  540. 30  EMS_LOW_OS_MAP_REGION      INT    // Limits: 0 to 576, default 384
  541.                                       // NOTE: increments of 16
  542. 31  EMS_MEMORY_LIMIT           INT    // Limits: 0 to 32768, default 2048
  543.                                       // NOTE: increments of 16
  544. 32  HW_NOSOUND                 BOOL   // Default: off
  545. 33  HW_ROM_TO_RAM              BOOL   // Default: off
  546. 34  HW_TIMER                   BOOL   // Default: off
  547. 35  IDLE_SECONDS               INT    // Limits: 0 to 60, default 0
  548. 36  IDLE_SENSITIVITY           INT    // Limits: 1 to 100, default 75
  549. 37  KBD_ALTHOME_BYPASS         BOOL   // Default: off
  550. 38  KBD_BUFFER_EXTEND          BOOL   // Default: on
  551. 39  KBD_CTRL_BYPASS            STR    // Valid settings: NONE (default)
  552.                                       //                 ALT_ESC
  553.                                       //                 CTRL_ESC
  554. 40  KBD_RATE_LOCK              BOOL   // Default: off
  555. 41  MEM_EXCLUDE_REGIONS        STR    // Default: empty
  556. 42  MEM_INCLUDE_REGIONS        STR    // Default: empty
  557. 43  MOUSE_EXCLUSIVE_ACCESS     BOOL   // Default: off
  558. 44  PRINT_TIMEOUT              INT    // Limits: 1 to 3600, default 15
  559. 45  VIDEO_8514A_XGA_IOTRAP     BOOL   // Default: on
  560. 46  VIDEO_FASTPASTE            BOOL   // Default: off
  561. 47  VIDEO_MODE_RESTRICTION     ENUM   // Valid settings: NONE (default)
  562.                                       //                 CGA
  563.                                       //                 MONO
  564. 48  VIDEO_ONDEMAND_MEMORY      BOOL   // Default: on
  565. 49  VIDEO_RETRACE_EMULATION    BOOL   // Default: on
  566. 50  VIDEO_ROM_EMULATION        BOOL   // Default: on
  567. 51  VIDEO_SWITCH_NOTIFICATION  BOOL   // Default: off
  568. 52  VIDEO_WINDOW_REFRESH       INT    // Limits: 1 to 600, default 1
  569. 53  XMS_HANDLES                INT    // Limits: 0 to 128, default 32
  570. 54  XMS_MEMORY_LIMIT           INT    // Limits: 0 to 16384, default 2048
  571.                                       // NOTE: increments of 4
  572. 55  XMS_MINIMUM_HMA            INT    // Limits: 0 to 63, default 0
  573. 56  DOS_BACKGROUND_EXECUTION   BOOL   // Default: on
  574. 57  DPMI_NETWORK_BUFF_SIZE     INT    // Limits: 1 to 64, default 8
  575.  
  576.  
  577. ΓòÉΓòÉΓòÉ 6.33. User Definitions for other Applications ΓòÉΓòÉΓòÉ
  578.  
  579. REM ---------------------------------------------------------------------------
  580. REM Windows file browser
  581. REM ---------------------------------------------------------------------------
  582.     NAME                      WNBROWSE.EXE
  583.     TITLE                     File Browser
  584.     TYPE                      Windows
  585.     ASSOC_FILE                WNBROWSE.HLP
  586.     DEF_DIR                   \WNBROWSE
  587.     MOUSE_EXCLUSIVE_ACCESS    OFF
  588.     KBD_CTRL_BYPASS           CTRL_ESC
  589.     COMMON_SESSION            ON
  590.     VIDEO_SWITCH_NOTIFICATION ON
  591.     KBD_ALTHOME_BYPASS        ON
  592.     DPMI_MEMORY_LIMIT         5
  593.  
  594. REM ---------------------------------------------------------------------------
  595. REM WordPerfect 5.1 by WordPerfect
  596. REM ---------------------------------------------------------------------------
  597.     NAME                      WP.EXE
  598.     TITLE                     WordPerfect
  599.     TYPE                      DOS
  600.     ASSOC_FILE                WP.FIL
  601.     DEF_DIR                   \WP51
  602.     MOUSE_EXCLUSIVE_ACCESS    OFF
  603.     IDLE_SENSITIVITY          88
  604.  
  605. REM ---------------------------------------------------------------------------
  606. REM PMCAMERA OS/2 screen capture utility
  607. REM ---------------------------------------------------------------------------
  608.     NAME                      PMCAMERA.EXE
  609.     TITLE                     PM Screen Capture
  610.     TYPE                      OS/2
  611.     ASSOC_FILE                PMCAMERA.HLP
  612.     DEF_DIR                   \PMCAMERA
  613.  
  614.  
  615. ΓòÉΓòÉΓòÉ 6.34. Windows Applications Running under OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  616.  
  617. We apologize for the picture quality.  The original was not available. 
  618.  
  619.  
  620. ΓòÉΓòÉΓòÉ 6.35. Single Windows Application Running under OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  621.  
  622. We apologize for the picture quality.  The original was not available. 
  623.  
  624.  
  625. ΓòÉΓòÉΓòÉ 6.36. Single Windows Application(s) Running "Seamless" on the OS/2 Version 2.0 Desktop ΓòÉΓòÉΓòÉ
  626.  
  627. We apologize for the picture quality.  The original was not available. 
  628.  
  629.  
  630. ΓòÉΓòÉΓòÉ 6.37. Implementation of "Seamless" WIN-OS/2 VDM in OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  631.  
  632.  
  633. ΓòÉΓòÉΓòÉ 6.38. Installing Windows Support under OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  634.  
  635.  
  636. ΓòÉΓòÉΓòÉ 6.39. Defining a Windows Application to OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  637.  
  638.  
  639. ΓòÉΓòÉΓòÉ 6.40. Migrating the Windows Initialization Files ΓòÉΓòÉΓòÉ
  640.  
  641.  
  642. ΓòÉΓòÉΓòÉ 6.41. Detailed View of the WIN-OS/2 Data Connections ΓòÉΓòÉΓòÉ
  643.  
  644. We apologize for the picture quality.  The original was not available. 
  645.  
  646.  
  647. ΓòÉΓòÉΓòÉ 6.42. Low Level View of the WIN-OS/2 Printing Data Flow ΓòÉΓòÉΓòÉ
  648.  
  649. We apologize for the picture quality.  The original was not available. 
  650.  
  651.  
  652. ΓòÉΓòÉΓòÉ 6.43. File Structure of Adobe Type Manager ΓòÉΓòÉΓòÉ
  653.  
  654.  
  655. ΓòÉΓòÉΓòÉ 6.44. OS/2 Version 2.0 Clipboard Environment ΓòÉΓòÉΓòÉ
  656.  
  657. Note that not all data formats shown in this diagram will be supported by the 
  658. global clipboard server.  This is discussed in detail in Clipboard Support. 
  659.  
  660.  
  661. ΓòÉΓòÉΓòÉ 6.45. DDE Process between Windows Environments ΓòÉΓòÉΓòÉ
  662.  
  663.  
  664. ΓòÉΓòÉΓòÉ 6.46. DDE Process between Presentation Manager and Windows ΓòÉΓòÉΓòÉ
  665.  
  666.  
  667. ΓòÉΓòÉΓòÉ 6.47. Client/Server Structure for Operating System Extenders ΓòÉΓòÉΓòÉ
  668.  
  669.  
  670. ΓòÉΓòÉΓòÉ 6.48. The Program Page of the Settings Notebook ΓòÉΓòÉΓòÉ
  671.  
  672.  
  673. ΓòÉΓòÉΓòÉ 6.49. The Session Page of the Settings Notebook ΓòÉΓòÉΓòÉ
  674.  
  675.  
  676. ΓòÉΓòÉΓòÉ 6.50. The DOS Settings Dialog of the Settings Notebook ΓòÉΓòÉΓòÉ
  677.  
  678.  
  679. ΓòÉΓòÉΓòÉ 6.51. Setting Up a TSR Program ΓòÉΓòÉΓòÉ
  680.  
  681.  
  682. ΓòÉΓòÉΓòÉ 6.52. The DOS Settings Dialog of the Settings Notebook ΓòÉΓòÉΓòÉ
  683.  
  684.  
  685. ΓòÉΓòÉΓòÉ 6.53. The Program Page of the Settings Notebook for a VMB ΓòÉΓòÉΓòÉ
  686.  
  687. All that is needed in the Path and file name field is an asterisk. 
  688.  
  689.  
  690. ΓòÉΓòÉΓòÉ 6.54. DOS Settings - DOS_STARTUP_DRIVE ΓòÉΓòÉΓòÉ
  691.  
  692. This illustration shows the specification of a DOS diskette image named 
  693. DR-DOS50.VMB, located on hard disk. 
  694.  
  695.  
  696. ΓòÉΓòÉΓòÉ 6.55. VMB from an OS/2 V2.0 Program ΓòÉΓòÉΓòÉ
  697.  
  698. /*
  699.  *  BOOTA:  A simple program to start a DOS Boot session under OS/2 2.0.
  700.  *          This program can be run from an OS/2 command prompt and it
  701.  *          then starts to Boot DOS from the A: drive.
  702.  *
  703.  *  Last Modfied: 04/02/92
  704.  *
  705.  *  Author: Stacey Barnes
  706.  *  Modified: Jeff Muir
  707.  */
  708.  
  709. #define INCL_DOSSESMGR
  710. #define INCL_DOSMISC
  711. #include <os2.h>
  712.  
  713. /* messages used by BOOTA */
  714. PSZ pBootAMsg = "BOOTA: Booting DOS from A: Drive.\r\n";
  715. PSZ pBootSuccess = "Session started.\r\n";
  716. PSZ pBootFailure = "Session could not be started.\r\n";
  717.  
  718. STARTDATA startd;                  /* Session start information */
  719. USHORT    SessionID, ProcessID;    /* Session and Process ID for new session*/
  720.  
  721. void main(void)
  722. {
  723.   USHORT       rc;
  724.  
  725.   /* Print header message */
  726.   DosPutMessage(1,strlen(pBootAMsg),pBootAMsg);
  727.  
  728.   /* Init fields to Boot from A: drive */
  729.   startd.Length                   = sizeof(STARTDATA);
  730.   startd.Related                  = SSF_RELATED_INDEPENDENT;
  731.   startd.FgBg                     = SSF_FGBG_FORE;
  732.   startd.TraceOpt                 = SSF_TRACEOPT_NONE;
  733.   startd.PgmTitle                 = "Boot A: Drive";
  734.   startd.PgmName                  = NULL;
  735.   startd.PgmInputs                = NULL;
  736.   startd.TermQ                    = NULL;
  737.   startd.Environment              = "DOS_STARTUP_DRIVE=A:\0";
  738.   startd.InheritOpt               = SSF_INHERTOPT_PARENT;
  739.   startd.SessionType              = SSF_TYPE_VDM;
  740.  
  741.   /* Start the DOS Boot Session */
  742.   rc = DosStartSession( &startd, &SessionID, &ProcessID );
  743.  
  744.   /* Print out either Success or Failure message */
  745.   if(rc)
  746.     DosPutMessage(1,strlen(pBootFailure),pBootFailure);
  747.   else
  748.     DosPutMessage(1,strlen(pBootSuccess),pBootSuccess);
  749.  
  750. return;
  751. }
  752. This sample shows how to start a VMB from a DOS diskette by using an OS/2 V2.0 
  753. program. 
  754.  
  755.  
  756. ΓòÉΓòÉΓòÉ 6.56. Personal Communications/3270 for Windows running under OS/2 V2.0 ΓòÉΓòÉΓòÉ
  757.  
  758. We apologize for the picture quality.  The original was not available. In this 
  759. picture it is using the Token-Ring LAN gateway and running as a "seamless" 
  760. WIN-OS/2 application on the Workplace Shell desktop. 
  761.  
  762.  
  763. ΓòÉΓòÉΓòÉ 6.57. Memory Map of Extended Memory (HMA, UMA, and EMBs) ΓòÉΓòÉΓòÉ
  764.  
  765.  
  766. ΓòÉΓòÉΓòÉ 6.58. QENV.BAT Batch File ΓòÉΓòÉΓòÉ
  767.  
  768. @rem QENV.BAT
  769. @rem Purpose :     Query DOS environment size
  770. @rem Author  :     Bernd Westphal
  771. @rem W10390 VDM Lab - VDM Configuration
  772. @echo off
  773. cls
  774. echo Filling free environment space ....
  775. echo.
  776. echo Ignore any messages like "Out of environment space".
  777. echo.
  778. set Dummy1=Dummy.Text.to.fill.the.environment.space
  779. set Dummy2=%Dummy1%
  780. set Dummy3=%Dummy1%
  781. set Dummy4=%Dummy1%
  782. set Dummy5=%Dummy1%
  783. cls
  784. environ.exe
  785. set Dummy1=
  786. set Dummy2=
  787. set Dummy3=
  788. set Dummy4=
  789. set Dummy5=
  790. cls
  791. echo The dummy environment settings have been removed.
  792.  
  793.  
  794. ΓòÉΓòÉΓòÉ 6.59. C Source Code for ENVIRON.EXE ΓòÉΓòÉΓòÉ
  795.  
  796. /*******************************************************\
  797.  *  Program name: ENVIRON.C                            *
  798.  *  Created     : 5. May 1990                          *
  799.  *  Revised     :                                      *
  800.  *  Author      : Bernd Westphal                       *
  801.  *  Purpose     : Get DOS environment size for VDM lab *
  802.  *  Compile     : cl environ.c                         *
  803.  *  Input param : none                                 *
  804. \*******************************************************/
  805.  
  806. #include <stdio.h>
  807. #include <string.h>
  808. #include <ctype.h>
  809.  
  810. void main(argc, argv, envp)
  811.    int   argc;
  812.    char *argv[];
  813.    char *envp[];
  814. {
  815.    int   charcount = 0;                    /* # of char  */
  816.  
  817.    printf("Current environment settings:\n\n");
  818.    printf("-----------------------------\n");
  819.    while (*envp)
  820.    {
  821.       printf("%s\n", *envp);
  822.       charcount += strlen (*envp) + 1;     /* add 1 for the string terminator */
  823.       *envp++;
  824.    }
  825.    printf("-----------------------------\n");
  826.    printf("\nTotal environment size is %d bytes.\n\n", charcount);
  827.    printf("Press Enter to continue ...\n");
  828.    getchar();
  829. }
  830.  
  831.  
  832. ΓòÉΓòÉΓòÉ 6.60. INT19.BAS Source Code ΓòÉΓòÉΓòÉ
  833.  
  834. '*********************************************************
  835. '*  Program name: INT19.BAS                              *
  836. '*  Created     : 05/05/90                               *
  837. '*  Revised     :                                        *
  838. '*  Author      : Bernd Westphal                         *
  839. '*  Purpose     : Execute INT 19h in an OS/2             *
  840. '*                VDM environment. Only the current      *
  841. '*                should be terminated.                  *
  842. '*  Compiler    : IBM BASIC Compiler/2 V1.00             *
  843. '*  Compile     : BASCOM INT19 /O                        *
  844. '*  Link        : LINK INT19;                            *
  845. '*  Input param : none                                   *
  846. '*********************************************************
  847.  
  848. ' Variable definition for Interrupt call
  849. TYPE RegType
  850.    ax    AS INTEGER
  851.    bx    AS INTEGER
  852.    cx    AS INTEGER
  853.    dx    AS INTEGER
  854.    bp    AS INTEGER
  855.    si    AS INTEGER
  856.    di    AS INTEGER
  857.    flags AS INTEGER
  858. END TYPE
  859.  
  860. DECLARE SUB Interrupt (intnum AS INTEGER, inreg AS RegType, outreg AS RegType)
  861.  
  862. DIM InRegs AS RegType
  863. DIM OutRegs AS RegType
  864.  
  865.    ' *** Program code ***
  866.    CLS
  867.    COLOR 15
  868.    PRINT "OS/2 Virtual DOS Machine + INT 19h"
  869.    PRINT STRING$(80, 196);
  870.    PRINT
  871.    PRINT "Execution of INT 19h under DOS on a 8086 processor"
  872.    PRINT "will reboot the system."
  873.    PRINT
  874.    PRINT "To prevent a system reboot running under OS/2 Version 2.0,"
  875.    PRINT "the Virtual DOS Machine Manager terminates the current"
  876.    PRINT "VDM if an INT 19h occurs."
  877.    PRINT
  878.    PRINT "Press Enter to execute the INT 19h interrupt"
  879.    PRINT "or press Esc to terminate."
  880.    PRINT
  881.    PRINT "Your choice: ";
  882. GetChr: kb$ = INPUT$(1)
  883.    SELECT CASE kb$
  884.       CASE CHR$(27)
  885.            CLS
  886.            END
  887.  
  888.       CASE CHR$(13)
  889.            PRINT "OK, restarting ..."
  890.            CALL Int86(&H19, InRegs, OutRegs)
  891.  
  892.       CASE ELSE
  893.            GOTO GetChr
  894.    END SELECT
  895. This program runs in compiled BASIC only, because the Int86 function call is 
  896. not available in interpreted BASIC. 
  897.  
  898.  
  899. ΓòÉΓòÉΓòÉ 6.61. GRAPHIC.BAS Source Code ΓòÉΓòÉΓòÉ
  900.  
  901. '*********************************************************
  902. '*  Program name: GRAPHIC.BAS                            *
  903. '*  Created     : 05/14/90                               *
  904. '*  Revised     :                                        *
  905. '*  Author      : Bernd Westphal                         *
  906. '*  Purpose     : Draw some graphics                     *
  907. '*                for VDM clipboard lab session          *
  908. '*  Compiler    : IBM BASIC Compiler/2 V1.00             *
  909. '*  Compile     : BASCOM GRAPHIC /O                      *
  910. '*  Link        : LINK GRAPHIC;                          *
  911. '*  Input param : none                                   *
  912. '*********************************************************
  913.  
  914.    SCREEN 2                           ' select 640 x 200 graphics mode
  915.    CLS                                ' clear the screen
  916.    FOR X=1 TO 640 STEP 10
  917.       LINE (320,199)-(X,0)            ' draw some lines
  918.    NEXT
  919.    FOR X=1 TO 640 STEP 10
  920.       LINE (320,0)-(X,199)            ' draw some lines
  921.    NEXT
  922.    LOCATE 12,31                       ' position the cursor
  923.    PRINT SPACE$(21)                   ' print 21 blanks
  924.    LOCATE 13,31                       ' position the cursor
  925.    PRINT " IBM ITSC Boca Raton "      ' print some text
  926.    LOCATE 14,31                       ' position the cursor
  927.    PRINT SPACE$(21)                   ' print 21 blanks
  928.    KB$ = INPUT$(1)                    ' check for keystroke
  929.    SYSTEM                             ' return to DOS
  930.  
  931.  
  932. ΓòÉΓòÉΓòÉ 6.62. SOUND.BAS Source Code ΓòÉΓòÉΓòÉ
  933.  
  934. '*********************************************************
  935. '*  Program name: SOUND.BAS                              *
  936. '*  Created     : 05/14/90                               *
  937. '*  Revised     :                                        *
  938. '*  Author      : Bernd Westphal                         *
  939. '*  Purpose     : Access the speaker system in a         *
  940. '*                VDM environment                        *
  941. '*                Only 1 VDM has access to the speaker   *
  942. '*  Compiler    : IBM BASIC Compiler/2                   *
  943. '*  Compile     : BASCOM SOUND /O;                       *
  944. '*  Link        : Link SOUND;                            *
  945. '*  Input param : none                                   *
  946. '*********************************************************
  947.  
  948.     CLS                           ' clear the screen
  949.     PLAY ON                       ' trap background music events
  950.     ON PLAY(3) GOSUB PlayMusic    ' If there are less than 3 notes
  951.                                   ' in the buffer gosub line 1000
  952.     PRINT "Press ENTER to end."   ' display info, how to end program
  953.     '
  954.     PLAY "MB"                     ' background option for PLAY
  955.     GOSUB PlayMusic               ' start the music
  956.     '
  957.     kb$ = ""                      ' keyboard input buffer
  958.     WHILE kb$ = ""                ' start of loop
  959.        LOCATE 3, 1                ' position the cursor
  960.        COLOR c                    ' change color and print some text,
  961.                                   ' to show, that music executes
  962.                                   ' independent
  963.        PRINT "Playing your favorite music ..."
  964.        c = c + 1                  ' next color
  965.        IF c > 15 then c = 1       ' no blinking mode
  966.        kb$ = INKEY$               ' get a character if present
  967.     WEND                          ' end of loop
  968.     COLOR 7                       ' white on black
  969.     SYSTEM                        ' return to DOS
  970.  
  971. PlayMusic:
  972.    PLAY "t180 o2 p2 p8 L8 GGG L2 E- p24 p8 L8 FFF L2 D"
  973.    RETURN
  974.  
  975.  
  976. ΓòÉΓòÉΓòÉ 7. Tables ΓòÉΓòÉΓòÉ
  977.  
  978.  PIC Initialization Control Words 
  979.  PIC Operation Control Words 
  980.  List of Supported Video Configurations 
  981.  Graphical Applications Programs Support under OS/2 Version 2.0 
  982.  Driver Letter Assignment 
  983.  Free Base Memory 
  984.  Location of AUTOEXEC.BAT and CONFIG.SYS 
  985.  Type of Expanded Memory 
  986.  
  987.  
  988. ΓòÉΓòÉΓòÉ 7.1. PIC Initialization Control Words ΓòÉΓòÉΓòÉ
  989.  
  990.  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  991.  Γöé PIC Initialization Control Words                                      Γöé
  992.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  993.  Γöé ICW      Γöé FIELD    Γöé EXPLANATION                         Γöé SUPPORTED Γöé
  994.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  995.  Γöé ICW1     Γöé D0       Γöé 1 = ICW4 needed                     Γöé Supported Γöé
  996.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  997.  Γöé          Γöé          Γöé 0 = no ICW4 needed                  Γöé Supported Γöé
  998.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  999.  Γöé          Γöé D1       Γöé 1 = single PIC                      Γöé Ignored   Γöé
  1000.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1001.  Γöé          Γöé          Γöé 0 = cascade mode (slaves)           Γöé Supported Γöé
  1002.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1003.  Γöé          Γöé D2       Γöé 1 = call address interval of 4      Γöé Ignored   Γöé
  1004.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1005.  Γöé          Γöé          Γöé 0 = call address interval of 8      Γöé Ignored   Γöé
  1006.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1007.  Γöé          Γöé D3       Γöé 1 = level triggered mode            Γöé Ignored   Γöé
  1008.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1009.  Γöé          Γöé          Γöé 0 = edge triggered mode             Γöé Supported Γöé
  1010.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1011.  Γöé          Γöé D4       Γöé 1                                   Γöé           Γöé
  1012.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1013.  Γöé          Γöé D5-D7    Γöé A7-A5 of int vector in 8080 mode    Γöé Ignored   Γöé
  1014.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1015.  Γöé ICW2     Γöé D0-D2    Γöé                                     Γöé Ignored   Γöé
  1016.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1017.  Γöé          Γöé D3-D7    Γöé base int vector number in 8086 mode Γöé Supported Γöé
  1018.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1019.  Γöé ICW3     Γöé          Γöé Ignore if slave is not IRQ2         Γöé           Γöé
  1020.  Γöé (Master) Γöé          Γöé                                     Γöé           Γöé
  1021.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1022.  Γöé          Γöé D0-D7    Γöé 1 = IRQ has a slave connected       Γöé           Γöé
  1023.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1024.  Γöé          Γöé          Γöé 0 = IRQ does not have a slave con-  Γöé           Γöé
  1025.  Γöé          Γöé          Γöé nected                              Γöé           Γöé
  1026.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1027.  Γöé ICW3     Γöé          Γöé Ignore if slave is not IRQ2         Γöé           Γöé
  1028.  Γöé (Slave)  Γöé          Γöé                                     Γöé           Γöé
  1029.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1030.  Γöé          Γöé D0-D2    Γöé slave ID                            Γöé           Γöé
  1031.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1032.  Γöé          Γöé D3-D7    Γöé 0                                   Γöé           Γöé
  1033.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1034.  Γöé ICW4     Γöé D0       Γöé 1 = 8086/8088 mode                  Γöé Supported Γöé
  1035.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1036.  Γöé          Γöé          Γöé 0 = 8080/8085 mode                  Γöé Ignored   Γöé
  1037.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1038.  Γöé D1       Γöé 1 = auto Γöé Ignored                             Γöé           Γöé
  1039.  Γöé          Γöé EOI      Γöé                                     Γöé           Γöé
  1040.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1041.  Γöé          Γöé          Γöé 0 = normal EOI                      Γöé Supported Γöé
  1042.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1043.  Γöé          Γöé D2-D3    Γöé 0x = non-buffered mode              Γöé Supported Γöé
  1044.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1045.  Γöé          Γöé          Γöé 10 = buffered mode/slave            Γöé Ignored   Γöé
  1046.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1047.  Γöé          Γöé          Γöé 11 = buffered mode/master           Γöé Ignored   Γöé
  1048.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1049.  Γöé          Γöé D4       Γöé 1 = special fully nested mode       Γöé Ignored   Γöé
  1050.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1051.  Γöé          Γöé          Γöé 0 = not special fully nested mode   Γöé Supported Γöé
  1052.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1053.  Γöé          Γöé D5-D7    Γöé 0                                   Γöé           Γöé
  1054.  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1055.  
  1056.  
  1057. ΓòÉΓòÉΓòÉ 7.2. PIC Operation Control Words ΓòÉΓòÉΓòÉ
  1058.  
  1059.  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1060.  Γöé PIC Operation Control Words                                        Γöé
  1061.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1062.  Γöé OCW   Γöé FIELD  Γöé EXPLANATION                           Γöé SUPPORTED Γöé
  1063.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1064.  Γöé OCW1  Γöé D0-D7  Γöé IMR (interrupt mask register)         Γöé Supported Γöé
  1065.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1066.  Γöé       Γöé        Γöé    1 = IRQ masked (disabled)          Γöé           Γöé
  1067.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1068.  Γöé       Γöé        Γöé    0 = IRQ unmasked (enabled)         Γöé           Γöé
  1069.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1070.  Γöé OCW2  Γöé D0-D2  Γöé IRQ level to be acted upon            Γöé           Γöé
  1071.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1072.  Γöé       Γöé D3-D4  Γöé 0                                     Γöé           Γöé
  1073.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1074.  Γöé       Γöé D5-D7  Γöé EOI command                           Γöé           Γöé
  1075.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1076.  Γöé       Γöé        Γöé 000 = rotate in auto EOI mode (clear) Γöé Ignored   Γöé
  1077.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1078.  Γöé       Γöé        Γöé 001 = non-specific EOI                Γöé Supported Γöé
  1079.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1080.  Γöé       Γöé        Γöé 010 = no operand                      Γöé Supported Γöé
  1081.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1082.  Γöé       Γöé        Γöé 011 = specific EOI                    Γöé Supported Γöé
  1083.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1084.  Γöé       Γöé        Γöé 100 = rotate in auto EOI mode (set)   Γöé Ignored   Γöé
  1085.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1086.  Γöé       Γöé        Γöé 101 = rotate on non-specific EOI      Γöé Ignored   Γöé
  1087.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1088.  Γöé       Γöé        Γöé 110 = set priority command            Γöé Ignored   Γöé
  1089.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1090.  Γöé       Γöé        Γöé 111 = rotate on specific EOI          Γöé Ignored   Γöé
  1091.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1092.  Γöé OCW3  Γöé D0-D1  Γöé read register command                 Γöé           Γöé
  1093.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1094.  Γöé       Γöé        Γöé 00 = no action                        Γöé Supported Γöé
  1095.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1096.  Γöé       Γöé        Γöé 01 = no action                        Γöé Supported Γöé
  1097.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1098.  Γöé       Γöé        Γöé 10 = read IR register                 Γöé Supported Γöé
  1099.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1100.  Γöé       Γöé        Γöé 11 = read IS register                 Γöé Supported Γöé
  1101.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1102.  Γöé       Γöé D2     Γöé 1 = poll command                      Γöé Ignored   Γöé
  1103.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1104.  Γöé       Γöé        Γöé 0 = no poll command                   Γöé Supported Γöé
  1105.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1106.  Γöé       Γöé D3     Γöé 1                                     Γöé           Γöé
  1107.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1108.  Γöé       Γöé D4     Γöé 0                                     Γöé           Γöé
  1109.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1110.  Γöé       Γöé D5-D6  Γöé Special mask mode                     Γöé           Γöé
  1111.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1112.  Γöé       Γöé        Γöé 00 = no action                        Γöé Supported Γöé
  1113.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1114.  Γöé       Γöé        Γöé 01 = no action                        Γöé Supported Γöé
  1115.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1116.  Γöé       Γöé        Γöé 10 = reset special mask               Γöé Ignored   Γöé
  1117.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1118.  Γöé       Γöé        Γöé 11 = set special mask                 Γöé Ignored   Γöé
  1119.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1120.  Γöé       Γöé D7     Γöé 0                                     Γöé           Γöé
  1121.  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1122.  
  1123.  
  1124. ΓòÉΓòÉΓòÉ 7.3. List of Supported Video Configurations ΓòÉΓòÉΓòÉ
  1125.  
  1126. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1127. Γöé List of Supported Video Configurations                                 Γöé
  1128. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1129. Γöé EXAMPLE Γöé SIZE Γöé COLOR Γöé ADAPTER Γöé RESOLUTION Γöé MEMORY Γöé COLORS/GRAYS  Γöé
  1130. Γöé DIS-    Γöé (IN.)Γöé       Γöé         Γöé            Γöé        Γöé               Γöé
  1131. Γöé PLAYS   Γöé      Γöé       Γöé         Γöé            Γöé        Γöé               Γöé
  1132. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1133. Γöé Mono    Γöé -    Γöé Mono  Γöé Mono    Γöé Supported  Γöé -      Γöé -             Γöé
  1134. Γöé         Γöé      Γöé       Γöé         Γöé as sec-    Γöé        Γöé               Γöé
  1135. Γöé         Γöé      Γöé       Γöé         Γöé ondary     Γöé        Γöé               Γöé
  1136. Γöé         Γöé      Γöé       Γöé         Γöé display    Γöé        Γöé               Γöé
  1137. Γöé         Γöé      Γöé       Γöé         Γöé only       Γöé        Γöé               Γöé
  1138. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1139. Γöé CGA     Γöé -    Γöé B&W   Γöé CGA     Γöé 640x200    Γöé -      Γöé -             Γöé
  1140. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1141. Γöé ECD     Γöé -    Γöé B&W   Γöé EGA     Γöé 640x350    Γöé 64K    Γöé no 4-color    Γöé
  1142. Γöé Monitor Γöé      Γöé       Γöé         Γöé            Γöé        Γöé support, uses Γöé
  1143. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé EGA/Mono      Γöé
  1144. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé driver        Γöé
  1145. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1146. Γöé ECD     Γöé -    Γöé Color Γöé EGA     Γöé 640x350    Γöé 128KB  Γöé 16 colors     Γöé
  1147. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1148. Γöé -       Γöé -    Γöé -     Γöé -       Γöé 640x350    Γöé 192KB  Γöé 16 colors     Γöé
  1149. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1150. Γöé -       Γöé -    Γöé -     Γöé -       Γöé 640x350    Γöé 256KB  Γöé 16 colors     Γöé
  1151. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1152. Γöé Mono    Γöé -    Γöé B&W   Γöé EGA     Γöé 640x350    Γöé any    Γöé no reverse    Γöé
  1153. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé memory Γöé video, blink  Γöé
  1154. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé size   Γöé or intense    Γöé
  1155. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé support       Γöé
  1156. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1157. Γöé RGB     Γöé -    Γöé EGA   Γöé Color   Γöé 640x200    Γöé any    Γöé 16 Colors     Γöé
  1158. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé memory Γöé               Γöé
  1159. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé size   Γöé               Γöé
  1160. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1161. Γöé EGA     Γöé -    Γöé -     Γöé EGA     Γöé -          Γöé -      Γöé Not supported Γöé
  1162. Γöé         Γöé      Γöé       Γöé w/2xx   Γöé            Γöé        Γöé               Γöé
  1163. Γöé         Γöé      Γöé       Γöé port    Γöé            Γöé        Γöé               Γöé
  1164. Γöé         Γöé      Γöé       Γöé config. Γöé            Γöé        Γöé               Γöé
  1165. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1166. Γöé 8503    Γöé 12   Γöé Mono  Γöé VGA     Γöé 640x480    Γöé -      Γöé 16 Grays      Γöé
  1167. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1168. Γöé 8512    Γöé 14   Γöé Color Γöé VGA     Γöé 640x480    Γöé -      Γöé 16 Colors     Γöé
  1169. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1170. Γöé 8513    Γöé 12   Γöé Color Γöé VGA     Γöé 640x480    Γöé -      Γöé 16 Colors     Γöé
  1171. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1172. Γöé 8514    Γöé 16   Γöé Color Γöé VGA     Γöé 640x480    Γöé -      Γöé 16 Colors     Γöé
  1173. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1174. Γöé 8503    Γöé 12   Γöé Mono  Γöé 8514/A  Γöé 640x480    Γöé -      Γöé 16 and 64     Γöé
  1175. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé Grays         Γöé
  1176. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1177. Γöé 8512    Γöé 14   Γöé Color Γöé 8514/A  Γöé 640x480    Γöé -      Γöé 16 and 256    Γöé
  1178. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé Colors        Γöé
  1179. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1180. Γöé 8513    Γöé 12   Γöé Color Γöé 8514/A  Γöé 640x480    Γöé -      Γöé 16 and 256    Γöé
  1181. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé Colors        Γöé
  1182. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1183. Γöé 8514    Γöé 16   Γöé Color Γöé 8514/A  Γöé 1024x768   Γöé -      Γöé 16 and 256    Γöé
  1184. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé Colors        Γöé
  1185. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1186. Γöé 8503    Γöé 12   Γöé Mono  Γöé XGA     Γöé 640x480    Γöé 512KB  Γöé 64 Grays      Γöé
  1187. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1188. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé 1MB    Γöé 64 Grays      Γöé
  1189. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1190. Γöé 8513    Γöé 12   Γöé Color Γöé XGA     Γöé 640x480    Γöé 512KB  Γöé 256 Colors    Γöé
  1191. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1192. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé 1MB    Γöé 256 Colors    Γöé
  1193. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1194. Γöé 8512    Γöé 14   Γöé Color Γöé XGA     Γöé 640x480    Γöé 1MB    Γöé 65536 Colors  Γöé
  1195. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1196. Γöé 8515    Γöé 14   Γöé Color Γöé XGA     Γöé 640x480    Γöé 512KB  Γöé 256 Colors    Γöé
  1197. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1198. Γöé         Γöé      Γöé       Γöé         Γöé 1024x768   Γöé 512KB  Γöé 16 Colors     Γöé
  1199. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1200. Γöé         Γöé      Γöé       Γöé         Γöé 640x480    Γöé 1MB    Γöé 256/65536     Γöé
  1201. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé Colors        Γöé
  1202. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1203. Γöé         Γöé      Γöé       Γöé         Γöé 1024x768   Γöé 1MB    Γöé 16/256 Colors Γöé
  1204. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1205. Γöé 8604    Γöé 15   Γöé Mono  Γöé XGA     Γöé 640x480    Γöé 512KB  Γöé 64 Grays      Γöé
  1206. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1207. Γöé         Γöé      Γöé       Γöé         Γöé 640x480    Γöé 1MB    Γöé 64 Grays      Γöé
  1208. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1209. Γöé 8507    Γöé 19   Γöé Mono  Γöé XGA     Γöé 1024x768   Γöé 512KB  Γöé 16 Grays      Γöé
  1210. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1211. Γöé         Γöé      Γöé       Γöé         Γöé 1024x768   Γöé 1MB    Γöé 16/64 Grays   Γöé
  1212. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1213. Γöé 8514    Γöé 16   Γöé Color Γöé XGA     Γöé 640x480    Γöé 512KB  Γöé 256 Colors    Γöé
  1214. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1215. Γöé         Γöé      Γöé       Γöé         Γöé 1024x768   Γöé 512KB  Γöé 16 Colors     Γöé
  1216. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1217. Γöé         Γöé      Γöé       Γöé         Γöé 640x480    Γöé 1MB    Γöé 256/65536     Γöé
  1218. Γöé         Γöé      Γöé       Γöé         Γöé            Γöé        Γöé Colors        Γöé
  1219. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1220. Γöé         Γöé      Γöé       Γöé         Γöé 1024x768   Γöé 1MB    Γöé 16/256 Colors Γöé
  1221. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1222. Γöé 8514    Γöé -    Γöé Color Γöé XGA     Γöé 1024x768   Γöé 512KB  Γöé 16 Colors     Γöé
  1223. Γöé Compat- Γöé      Γöé       Γöé         Γöé            Γöé        Γöé               Γöé
  1224. Γöé ible    Γöé      Γöé       Γöé         Γöé            Γöé        Γöé               Γöé
  1225. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1226. Γöé         Γöé      Γöé       Γöé         Γöé 640x480    Γöé 1MB    Γöé 65536 Colors  Γöé
  1227. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1228. Γöé         Γöé      Γöé       Γöé         Γöé 1024x768   Γöé 1MB    Γöé 16/256 Colors Γöé
  1229. ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1230.  
  1231.  
  1232. ΓòÉΓòÉΓòÉ 7.4. Graphical Applications Programs Support under OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  1233.  
  1234. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1235. Γöé Graphical Applications Programs Support under OS/2 Version 2.0          Γöé
  1236. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1237. Γöé       Γöé        Γöé    Γöé    Γöé         WINDOWS APPS       Γöé                 Γöé
  1238. Γöé       Γöé        Γöé    Γöé    Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ                 Γöé
  1239. Γöé       Γöé        Γöé    Γöé    Γöé  FULL SCREEN (FS)Γöé         Γöé     DOS APPS    Γöé
  1240. Γöé       Γöé        Γöé    Γöé    Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ         Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1241. Γöé       Γöé        Γöé    Γöé    Γöé MATCHES Γöé USING  Γöé         Γöé MATCHES Γöé USING Γöé
  1242. Γöé       Γöé        Γöé    Γöé    Γöé DESKTOP Γöé  VGA   Γöé         Γöé DESKTOP Γöé VGA   Γöé
  1243. Γöé       ΓöéSYSTEM  Γöé    ΓöéVIO Γöé  MODE   Γöé  MODE  ΓöéWIN-OS/2 Γöé  MODE   Γöé MODE  Γöé
  1244. ΓöéTYPE OFΓöéDESKTOP ΓöéPM  ΓöéOS/2Γö£ΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöñ WINDOW  Γö£ΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöñ
  1245. ΓöéVIDEO  ΓöéMODE    ΓöéAPPSΓöéAPPSΓöé A  Γöé B  Γöé A Γöé B  Γöé (Win)   Γöé FS ΓöéWIN ΓöéFS ΓöéWINΓöé
  1246. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöñ
  1247. Γöé XGA   Γöé XGA    Γöé R  Γöé F  Γöé R  Γöé F  Γöé R Γöé F  Γöé N/A     Γöé F  Γöé X  Γöé F ΓöéX  Γöé
  1248. Γöé       Γöé        Γöé    Γöé    Γöé    Γöé    Γöé   Γöé    Γöé         Γöé    Γöé    Γöé   Γöé   Γöé
  1249. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöñ
  1250. Γöé XGA   Γöé VGA    Γöé R  Γöé F  Γöé R  Γöé PF Γöé R Γöé PF Γöé R       Γöé PF Γöé PF'Γöé PFΓöéPF'Γöé
  1251. Γöé       Γöé        Γöé    Γöé    Γöé    Γöé    Γöé   Γöé    Γöé         Γöé    Γöé    Γöé   Γöé   Γöé
  1252. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöñ
  1253. Γöé VGA   Γöé VGA    Γöé R  Γöé F  Γöé R  Γöé PF Γöé R Γöé PF Γöé R       Γöé PF Γöé PF'Γöé PFΓöéPF'Γöé
  1254. Γöé       Γöé        Γöé    Γöé    Γöé    Γöé    Γöé   Γöé    Γöé         Γöé    Γöé    Γöé   Γöé   Γöé
  1255. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöñ
  1256. Γöé 8514  Γöé VGA    Γöé R  Γöé F  Γöé R  Γöé PF Γöé R Γöé PF Γöé R       Γöé PF Γöé PF'Γöé PFΓöéPF'Γöé
  1257. Γöé       Γöé        Γöé    Γöé    Γöé    Γöé    Γöé   Γöé    Γöé         Γöé    Γöé    Γöé   Γöé   Γöé
  1258. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöñ
  1259. Γöé 8514  Γöé 8514   Γöé R  Γöé F  Γöé R  Γöé F  Γöé R Γöé R  Γöé N/A     Γöé F  Γöé X  Γöé R ΓöéR  Γöé
  1260. Γöé       Γöé        Γöé    Γöé    Γöé    Γöé    Γöé   Γöé    Γöé         Γöé    Γöé    Γöé   Γöé   Γöé
  1261. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöñ
  1262. Γöé EGA   Γöé EGA    Γöé R  Γöé F  Γöé R  Γöé PF ΓöéN/AΓöé N/AΓöé N/A     Γöé PF Γöé PF'ΓöéN/AΓöéN/AΓöé
  1263. Γöé       Γöé        Γöé    Γöé    Γöé    Γöé    Γöé   Γöé    Γöé         Γöé    Γöé    Γöé   Γöé   Γöé
  1264. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöñ
  1265. Γöé CGA   Γöé CGA    Γöé R  Γöé F  Γöé R  Γöé R  ΓöéN/AΓöé N/AΓöé N/A     Γöé R  Γöé R  ΓöéN/AΓöéN/AΓöé
  1266. Γöé       Γöé        Γöé    Γöé    Γöé    Γöé    Γöé   Γöé    Γöé         Γöé    Γöé    Γöé   Γöé   Γöé
  1267. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöñ
  1268. Γöé  LEGEND:                                                                Γöé
  1269. Γöé           R      Runs                                                   Γöé
  1270. Γöé           PF     Runs when PM has control of the screen, or when the    Γöé
  1271. Γöé                  application is in a foreground session                 Γöé
  1272. Γöé           PF'    Runs only when PM has control of the screen            Γöé
  1273. Γöé           F      Runs only when the application is in a foreground      Γöé
  1274. Γöé                  session                                                Γöé
  1275. Γöé           X      Not supported                                          Γöé
  1276. Γöé           N/A    Not applicable                                         Γöé
  1277. Γöé                                                                         Γöé
  1278. ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1279.  
  1280. Note:   Column A indicates the use of a Windows display driver that suppresses 
  1281. background output.  Column B indicates the use of a Windows display driver that 
  1282. does not suppress background output. 
  1283.  
  1284.  
  1285. ΓòÉΓòÉΓòÉ 7.5. Driver Letter Assignment ΓòÉΓòÉΓòÉ
  1286.  
  1287.  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1288.  Γöé Drive Letter Assignment.  This table shows the way drive     Γöé
  1289.  Γöé letter assignments may differ on a mixed FAT and HPFS hard   Γöé
  1290.  Γöé disk when booted under DOS and OS/2 Version 2.0              Γöé                         Γöé
  1291.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1292.  Γöé PARTITION/TYPE           Γöé DRIVE LETTER    Γöé DRIVE LETTER    Γöé
  1293.  Γöé                          Γöé UNDER OS/2      Γöé UNDER DOS       Γöé
  1294.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1295.  Γöé Primary Partition 1,     Γöé none            Γöé none            Γöé
  1296.  Γöé Boot Manager             Γöé                 Γöé                 Γöé
  1297.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1298.  Γöé Primary Partition 2, FAT Γöé C:              Γöé C:              Γöé
  1299.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1300.  Γöé Extended Partition, HPFS Γöé D:              Γöé none            Γöé
  1301.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1302.  Γöé Extended Partition, FAT  Γöé E:              Γöé D:              Γöé
  1303.  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1304.  
  1305.  
  1306. ΓòÉΓòÉΓòÉ 7.6. Free Base Memory ΓòÉΓòÉΓòÉ
  1307.  
  1308.  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1309.  Γöé Free Base Memory                                             Γöé
  1310.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1311.  Γöé SETTING     Γöé VDM DOS    Γöé DOS 5.0       Γöé DOS 4.0 Γöé DOS 3.3 Γöé
  1312.  Γöé             Γöé EMULATION  Γöé               Γöé         Γöé         Γöé
  1313.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1314.  Γöé DOS low     Γöé 610 KB     Γöé 566 KB        Γöé 588 KB  Γöé 545 KB  Γöé
  1315.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1316.  Γöé DOS high    Γöé 633 KB     Γöé 612 KB        Γöé -       Γöé -       Γöé
  1317.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1318.  Γöé With mode   Γöé 728 KB     Γöé 707 KB        Γöé 653 KB  Γöé 670 KB  Γöé
  1319.  Γöé restriction Γöé            Γöé               Γöé         Γöé         Γöé
  1320.  Γöé (CGA)       Γöé            Γöé               Γöé         Γöé         Γöé
  1321.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1322.  Γöé native DOS  Γöé -          Γöé 564 KB (low)  Γöé 545 KB  Γöé 562 KB  Γöé
  1323.  Γöé             Γöé            Γöé               Γöé         Γöé         Γöé
  1324.  Γöé             Γöé            Γöé 614 KB (high) Γöé         Γöé         Γöé
  1325.  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1326.  
  1327. Note:    Each configuration has HIMEM, EMS and Mouse drivers loaded.  Values are
  1328. approximate.
  1329.  
  1330.  
  1331. ΓòÉΓòÉΓòÉ 7.7. Location of AUTOEXEC.BAT and CONFIG.SYS ΓòÉΓòÉΓòÉ
  1332.  
  1333. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1334. Γöé Location of AUTOEXEC.BAT and CONFIG.SYS                                 Γöé
  1335. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1336. Γöé VDM TYPE                           Γöé LOCATION                           Γöé
  1337. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1338. Γöé Virtual Machine Boot from diskette Γöé drive A:                           Γöé
  1339. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1340. Γöé Virtual Machine Boot from diskette Γöé imbedded in diskette image file on Γöé
  1341. Γöé image                              Γöé the hard disk                      Γöé
  1342. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1343. Γöé Virtual Machine Boot from DOS boot Γöé DOS boot partition                 Γöé
  1344. Γöé partition                          Γöé                                    Γöé
  1345. Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1346. Γöé OS/2 V2.0 DOS emulator             Γöé root directory of OS/2 boot drive  Γöé
  1347. ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1348.  
  1349.  
  1350. ΓòÉΓòÉΓòÉ 7.8. Type of Expanded Memory ΓòÉΓòÉΓòÉ
  1351.  
  1352.  ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  1353.  Γöé Types of Expanded Memory.  Memory types utilized by VDMs.    Γöé
  1354.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1355.  Γöé ATTRIBUTE                           Γöé HMA  Γöé EMB  Γöé UMB      Γöé
  1356.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1357.  Γöé Is extended memory                  Γöé X    Γöé X    Γöé          Γöé
  1358.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1359.  Γöé Accessible from real mode           Γöé X    Γöé      Γöé X        Γöé
  1360.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1361.  Γöé Data may be stored                  Γöé X    Γöé X    Γöé X        Γöé
  1362.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1363.  Γöé Code may be executed from real mode Γöé X    Γöé      Γöé X        Γöé
  1364.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1365.  Γöé Interrupt handler may be stored     Γöé      Γöé      Γöé X        Γöé
  1366.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1367.  Γöé Size may be changed after initial   Γöé      Γöé X    Γöé          Γöé
  1368.  Γöé allocation                          Γöé      Γöé      Γöé          Γöé
  1369.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1370.  Γöé Minimum size                        Γöé 64KB Γöé 1KB  Γöé 16 bytes Γöé
  1371.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1372.  Γöé Maximum size for one                Γöé 64KB Γöé 64MB Γöé 384KB    Γöé
  1373.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1374.  Γöé Maximum size total                  Γöé 64KB Γöé 64MB Γöé 384KB    Γöé
  1375.  Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
  1376.  Γöé Number available                    Γöé 1    Γöé 255  Γöé 24KB     Γöé
  1377.  ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
  1378.  
  1379.  
  1380. ΓòÉΓòÉΓòÉ 8. Special Notices ΓòÉΓòÉΓòÉ
  1381.  
  1382. This publication is intended to help customers and system engineers to 
  1383. understand and utilize the new features in Version 2.0 of OS/2. The information 
  1384. in this publication is not intended as the specification of any programming 
  1385. interfaces that are provided by OS/2 Version 2.0. See the PUBLICATIONS section 
  1386. of the IBM Programming Announcement for OS/2 Version 2.0 for more information 
  1387. about what publications are considered to be product documentation. 
  1388.  
  1389. References in this publication to IBM products, programs or services do not 
  1390. imply that IBM intends to make these available in all countries in which IBM 
  1391. operates.  Any reference to an IBM product, program, or service is not intended 
  1392. to state or imply that only IBM's product, program, or service may be used. Any 
  1393. functionally equivalent program that does not infringe any of IBM's 
  1394. intellectual property rights may be used instead of the IBM product, program or 
  1395. service. 
  1396.  
  1397. Information in this book was developed in conjunction with use of the equipment 
  1398. specified, and is limited in application to those specific hardware and 
  1399. software products and levels. 
  1400.  
  1401. IBM may have patents or pending patent applications covering subject matter in 
  1402. this document.  The furnishing of this document does not give you any license 
  1403. to these patents.  You can send license inquiries, in writing, to the IBM 
  1404. Director of Commercial Relations, IBM Corporation, Purchase, NY 10577. 
  1405.  
  1406. The information contained in this document has not been submitted to any formal 
  1407. IBM test and is distributed AS IS. The information about non-IBM ("vendor") 
  1408. products in this manual has been supplied by the vendor and IBM assumes no 
  1409. responsibility for its accuracy completeness. The use of this information or 
  1410. the implementation of any of these techniques is a customer responsibility and 
  1411. depends on the customer's ability to evaluate and integrate them into the 
  1412. customer's operational environment.  While each item may have been reviewed by 
  1413. IBM for accuracy in a specific situation, there is no guarantee that the same 
  1414. or similar results will be obtained elsewhere.  Customers attempting to adapt 
  1415. these techniques to their own environments do so at their own risk. 
  1416.  
  1417. References in this publication to IBM products, programs or services do not 
  1418. imply that IBM intends to make these available in all countries in which IBM 
  1419. operates.  Any reference to an IBM product, program, or service is not intended 
  1420. to state or imply that only IBM's product, program, or service may be used. Any 
  1421. functionally equivalent program that does not infringe any of IBM's 
  1422. intellectual property rights may be used instead of the IBM product, program or 
  1423. service. 
  1424.  
  1425. This document has not been subjected to any formal review and has not been 
  1426. checked for technical accuracy.  Results may be individually evaluated for 
  1427. applicability to a particular installation.  You may discuss pertinent 
  1428. information from this document with a customer, and you may abstract pertinent 
  1429. information for presentation to your customers.  However, any code included is 
  1430. for internal information purposes only and may not be given to customers. If 
  1431. included code is identified as incidental programming, its use must conform to 
  1432. the guidelines in the relevant section of the sales manual. 
  1433.  
  1434. Any performance data contained in this document was obtained in a controlled 
  1435. environment based on the use of specific data and is presented only to 
  1436. illustrate techniques and procedures to assist IBM personnel to better 
  1437. understand IBM products.  The results that may be obtained in other operating 
  1438. environments may vary significantly.  Users of this document should verify the 
  1439. applicable data in their specific environment.  No performance data may be 
  1440. abstracted or reproduced and given to non-IBM personnel without prior written 
  1441. approval by Business Practices. 
  1442.  
  1443. Any performance data contained in this document was determined in a controlled 
  1444. environment, and therefore, the results that may be obtained in other operating 
  1445. environments may vary significantly. Users of this document should verify the 
  1446. applicable data for their specific environment. 
  1447.  
  1448. The following document contains examples of data and reports used in daily 
  1449. business operations.  To illustrate them as completely as possible, the 
  1450. examples contain the names of individuals, companies, brands, and products. 
  1451. All of these names are fictitious and any similarity to the names and addresses 
  1452. used by an actual business enterprise is entirely coincidental. 
  1453.  
  1454. Reference to PTF numbers that have not been released through the normal 
  1455. distribution process does not imply general availability. The purpose of 
  1456. including these reference numbers is to alert IBM customers to specific 
  1457. information relative to the implementation of the PTF when it becomes available 
  1458. to each customer according to the normal IBM PTF distribution process. 
  1459.  
  1460. You can reproduce a page in this document as a transparency, if that page has 
  1461. the copyright notice on it.  The copyright notice must appear on each page 
  1462. being reproduced. 
  1463.  
  1464. The following terms, which are denoted by an asterisk (*) in this publication, 
  1465. are trademarks of the International Business Machines Corporation in the United 
  1466. States and/or other countries: 
  1467.  
  1468.  AIX
  1469.  C/2
  1470.  IBM
  1471.  Micro Channel
  1472.  Operating System/2
  1473.  OS/2
  1474.  Personal System/2
  1475.  Presentation Manager
  1476.  SAA
  1477.  Systems Application Architecture
  1478.  Workplace Shell
  1479.  
  1480. The following terms, which are denoted by a double asterisk (**) in this 
  1481. publication, are trademarks of other companies. 
  1482.  
  1483. Adobe is a trademark of Adobe Systems Inc.
  1484. AST is a trademark of AST.
  1485. CP/M is a trademark of Digital Research Inc.
  1486. CompuServe is a trademark CompuServe Inc.
  1487. DR-DOS is a trademark of Digital Research Inc.
  1488. Excel is a trademark of Microsoft Corporation.
  1489. Helvetica is a trademark of Linotype Company.
  1490. HP and Hewlett-Packard are trademarks of Hewlett-Packard Corporation.
  1491. Intel is a trademark of Intel Corporation.
  1492. LaserJet is a trademark of Hewlett-Packard Corporation.
  1493. Lotus and Lotus 1-2-3 are trademarks of Lotus Development Corporation.
  1494. Microsoft is a trademark of Microsoft Corporation.
  1495. MS-DOS is a registered trademark of Microsoft Corporation.
  1496. SPF/2 is a trademark of Command Technology Corporation.
  1497. Times New Roman is a trademark of Monotype Corporation Limited.
  1498. Windows is a trademark of Microsoft Corporation.
  1499. WordPerfect is a trademark of Wordperfect Corporation.
  1500. 386, 486, SX are trademarks of Intel Corporation.
  1501. 80286, 80386 and 80486 are trademarks of Intel Corporation.
  1502.  
  1503.  
  1504. ΓòÉΓòÉΓòÉ 9. Preface ΓòÉΓòÉΓòÉ
  1505.  
  1506. This document provides an understanding of the architecture and function of the 
  1507. Multiple Virtual DOS Machines (MVDM) component of OS/2 Version 2.0, which 
  1508. allows concurrent execution of multiple DOS applications, each in its own 
  1509. virtual DOS machine.  Further, this document describes the support for Windows 
  1510. applications under OS/2 Version 2.0. 
  1511.  
  1512. This document contains information on the MVDM architecture and components, 
  1513. including the use of device drivers by DOS applications, and support for 
  1514. expanded and extended memory.  Other MVDM-related topics discussed in this 
  1515. document include the DOS Settings feature, which allows the user to determine 
  1516. the way in which a DOS application runs and the resources available to it, and 
  1517. Virtual Machine Boot, which allows the user to load any version of DOS into a 
  1518. virtual DOS machine to support the execution of version-dependent DOS 
  1519. applications. 
  1520.  
  1521. Support for Windows applications on the OS/2 Version 2.0 platform is another 
  1522. important topic examined in this document.  The document includes a discussion 
  1523. of Windows device drivers, inter-process communication between Windows, DOS, 
  1524. and OS/2 applications (including DDE and clipboard capabilities), and 
  1525. compatibility issues as they relate to Windows applications in the OS/2 Version 
  1526. 2.0 environment. 
  1527.  
  1528. This document is intended for: 
  1529.  
  1530.  Customer planners and technical support personnel who require an 
  1531.   understanding of DOS and Windows implementation in OS/2 Version 2.0. 
  1532.  
  1533.  IBM and IBM authorized dealer technical support personnel. 
  1534.  
  1535.  Programmers of DOS and Windows applications who wish to ensure compatibility 
  1536.   of their applications with the OS/2 Version 2.0 platform. 
  1537.  
  1538. The information contained in this document assumes that readers have a general 
  1539. familiarity with the DOS and Windows environments and the applications which 
  1540. run in these environments. 
  1541.  
  1542. The code examples used in this document are available in electronic form via 
  1543. CompuServe** or through a local IBM Support Bulletin Board System (BBS), as 
  1544. package RB3731.ZIP. IBM employees may obtain the code examples from the 
  1545. GG243731 PACKAGE on OS2TOOLS. 
  1546.  
  1547. The document is organized as follows: 
  1548.  
  1549.  Overview provides a brief introduction to the topics covered in this 
  1550.   document. 
  1551.  
  1552.   This chapter is recommended for all readers of the document. 
  1553.  
  1554.  MVDM Architecture describes the architecture of the Multiple Virtual DOS 
  1555.   Machines component of OS/2 Version 2.0, including information regarding the 
  1556.   creation and management of virtual DOS machines. 
  1557.  
  1558.   This chapter is recommended for those readers who require an understanding of 
  1559.   the way in which OS/2 Version 2.0 manages virtual DOS machine resources and 
  1560.   an understanding of how MVDM implementation differs from the implementation 
  1561.   of the DOS Compatibility Box in previous versions of OS/2. 
  1562.  
  1563.  8086 Emulation discusses 8086 emulation under OS/2 Version 2.0. 
  1564.  
  1565.   This chapter is recommended for those readers who desire an overview of the 
  1566.   8086 emulation capabilities of the Intel 80386 processor, which are exploited 
  1567.   by OS/2 Version 2.0, and who wish to compare the functions this environment 
  1568.   provides to DOS applications with those available to DOS applications under 
  1569.   previous versions of OS/2. 
  1570.  
  1571.  MVDM DOS Emulation describes the way in which DOS emulation is achieved by 
  1572.   the MVDM component, and compares the functions available in a virtual DOS 
  1573.   machine to those available in native DOS 5.0.  Considerations for running a 
  1574.   DOS application under OS/2 Version 2.0 versus running it under native DOS are 
  1575.   also discussed. 
  1576.  
  1577.   This chapter is recommended for those readers who wish to compare the VDM 
  1578.   environment under OS/2 Version 2.0 with that of DOS 5.0. 
  1579.  
  1580.  Device Drivers discusses MVDM  device drivers.  It describes the device 
  1581.   drivers which are supported in a virtual DOS machine under OS/2 Version 2.0 
  1582.   and explains how device drivers are implemented, differentiating between 
  1583.   physical device drivers and virtual device drivers.  Virtual DOS machine 
  1584.   interrupt support is also discussed. 
  1585.  
  1586.   This chapter is intended primarily for programmers who plan to write device 
  1587.   drivers for DOS applications that will run under OS/2 Version 2.0 and for 
  1588.   technical support personnel who wish an in-depth understanding of virtual DOS 
  1589.   machine device driver support. 
  1590.  
  1591.  Memory Extender Support describes the support for DOS memory extenders 
  1592.   provided in the MVDM component.  This chapter explains expanded and extended 
  1593.   memory support. 
  1594.  
  1595.   This chapter is recommended for those readers who wish to understand the way 
  1596.   in which MVDM supports applications which make use of more than 640KB of 
  1597.   conventional memory. 
  1598.  
  1599.  Installing and Migrating Applications describes installing and migrating DOS 
  1600.   and Windows applications to OS/2 V2.0 It also discusses the use of the 
  1601.   utility for creating a customized migration database. 
  1602.  
  1603.   This chapter is recommended for system administrators responsible for setting 
  1604.   up applications for OS/2 V2.0 users. 
  1605.  
  1606.  Windows Applications describes the implementation of Windows application 
  1607.   support under OS/2 Version 2.0. 
  1608.  
  1609.   This chapter is intended for those readers who wish to run Windows 
  1610.   applications under OS/2 Version 2.0. 
  1611.  
  1612.  DOS Protected Mode Interface describes the implementation of the DOS Protect 
  1613.   Mode Interface, DPMI. 
  1614.  
  1615.   This chapter is intended for those readers who wish to run Windows 
  1616.   applications under OS/2 Version 2.0 and who also need a deeper understanding 
  1617.   of the technical implications of this programming interface. 
  1618.  
  1619.  Running DOS Applications describes the way to define, configure and start DOS 
  1620.   applications under OS/2 Version 2.0. 
  1621.  
  1622.   This chapter is recommended for those readers who wish to run DOS 
  1623.   applications under OS/2 Version 2.0, and who wish to define and configure 
  1624.   their application environment for optimum compatibility and performance. 
  1625.  
  1626.  DOS Settings describes the DOS Settings feature of MVDM.  This feature allows 
  1627.   the user to customize parameters which affect how an application runs in a 
  1628.   VDM and the resources available to it. 
  1629.  
  1630.   This chapter is recommended for every reader who plans to run DOS 
  1631.   applications under OS/2 Version 2.0. 
  1632.  
  1633.  Virtual Machine Boot describes the Virtual Machine Boot feature of MVDM, 
  1634.   which allows a specific version of DOS to be started within a virtual DOS 
  1635.   machine, thereby providing full compatibility for those applications which 
  1636.   require version-specific DOS features. 
  1637.  
  1638.   This chapter is recommended for readers who need to run such applications in 
  1639.   a VDM. 
  1640.  
  1641. The following appendixes are included in this document: 
  1642.  
  1643.  1. Running Personal Communications/3270 Version 2 for Windows explains how to 
  1644.     set up and run Personal Communications/3270 Version 2 for Windows in a 
  1645.     WIN-OS/2 window. 
  1646.  
  1647.  2. Running DOS PC Support/400 in OS/2 V2.0 explains how to set up and run DOS 
  1648.     PC Support/400 in a Virtual Machine Boot session. 
  1649.  
  1650.  3. Running Lotus 1-2-3 in a VDM explains how to set up and run Lotus 1-2-3 in 
  1651.     a virtual DOS machine session with EMS or DPMI support. 
  1652.  
  1653.  4. Memory Extender Architectures provides a brief overview of the 
  1654.     Lotus-Intel-Microsoft (LIM) Expanded Memory Specification (EMS) Version 4.0 
  1655.     and LIMA Extended Memory Specification (XMS) Version 2.0, for those readers 
  1656.     who desire an understanding of these specifications in the context of their 
  1657.     support by MVDM. 
  1658.  
  1659.  5. Multiple Virtual DOS Machines Lab Sessions provides a series of lab 
  1660.     exercises designed to illustrate the new functions and features of the 
  1661.     Multiple Virtual DOS Machines component of OS/2 Version 2.0.  The exercises 
  1662.     cover such topics as virtual DOS machine  configuration, use of the OS/2 
  1663.     clipboard, virtual DOS machine device drivers, and virtual DOS machine 
  1664.     video mode restrictions. 
  1665.  
  1666.  
  1667. ΓòÉΓòÉΓòÉ 10. Related Publications ΓòÉΓòÉΓòÉ
  1668.  
  1669. The following publications are considered particularly suitable for a more 
  1670. detailed discussion of the topics covered in this document. 
  1671.  
  1672. Prerequisite Publications 
  1673.  
  1674.  OS/2 Version 2.0 Installation Guide 
  1675.  
  1676.  OS/2 Version 2.0 Overview Guide 
  1677.  
  1678.  OS/2 Version 2.0 Online Documentation. 
  1679.  
  1680. Additional Publications 
  1681.  
  1682.  OS/2 V1.2 Standard Edition Internals and Evaluation, GG24-3466 
  1683.  
  1684.  OS/2 V1.3 Volume 1: New Features, GG24-3630 
  1685.  
  1686.  OS/2 V1.3 Volume 2: Print Subsystem, GG24-3631 
  1687.  
  1688.  OS/2 Version 2.0 - Volume 1:  Control Program, GG24-3730 
  1689.  
  1690.  OS/2 Version 2.0 - Volume 3:  Presentation Manager and Workplace Shell, 
  1691.   GG24-3732 
  1692.  
  1693.  OS/2 Version 2.0 - Volume 4:  Application Development, GG24-3774 
  1694.  
  1695.  OS/2 Version 2.0 - Volume 5:  Print Subsystem, GG24-3775 
  1696.  
  1697.  OS/2 Version 2.0 Remote Installation and Maintenance, GG24-3780 
  1698.  
  1699.  IBM DOS 5.0, Windows 3.0, Windows Connection 2.0, Personal 
  1700.   Communications/3270 2.0, GG24-3612 
  1701.  
  1702.  Intel 80386 System Software Writer's Guide, ISBN 1-55512-023-7 
  1703.  
  1704.  Virtual Control Program Interface (VCPI) Specification Version 1.0 
  1705.  
  1706.  DOS Protect Mode Interface (DPMI) Specification, Version 0.9 
  1707.  
  1708.  Expanded Memory Specification (EMS), Version 4.0 
  1709.  
  1710.  Extended Memory Specification (XMS), Version 2.0 
  1711.  
  1712.  IBM Personal System Technical Solutions Journal 
  1713.  
  1714.  IBM Personal System Developer Journal 
  1715.  
  1716.  Microsoft Systems Journal 
  1717.  
  1718.  Microsoft Windows Programming Reference 
  1719.  
  1720.  DOS 5.0 User's Guide and Reference 
  1721.  
  1722.  DOS 5.0 Technical Reference. 
  1723.  
  1724.  
  1725. ΓòÉΓòÉΓòÉ 11. Overview ΓòÉΓòÉΓòÉ
  1726.  
  1727. A significant new feature of IBM* OS/2* Version 2.0 is the ability to execute 
  1728. multiple DOS applications concurrently, with pre-emptive multitasking and full 
  1729. memory protection for each application.  Microsoft** Windows** applications are 
  1730. also supported in the same way.  These capabilities allow the use of OS/2 
  1731. Version 2.0 as an integration platform for DOS applications, Windows 
  1732. applications, and OS/2 applications in a seamless, fully functional 
  1733. environment. 
  1734.  
  1735. This chapter provides a brief overview of the OS/2 Version 2.0 product and the 
  1736. Multiple Virtual DOS Machines component which provides support for DOS and 
  1737. Windows applications.  DOS and Windows application support is then described in 
  1738. more detail in the remainder of the document. 
  1739.  
  1740.  
  1741. ΓòÉΓòÉΓòÉ 11.1. OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  1742.  
  1743. While this document focuses on Multiple Virtual DOS Machines and the support of 
  1744. Windows applications under OS/2 Version 2.0, it is useful to briefly review the 
  1745. highlights of OS/2 Version 2.0. 
  1746.  
  1747.  
  1748. ΓòÉΓòÉΓòÉ 11.1.1. OS/2 Version 2.0 Overview ΓòÉΓòÉΓòÉ
  1749.  
  1750. OS/2 Version 2.0 is an advanced multitasking, single-user operating system for 
  1751. IBM Personal System/2* computers and other computers equipped with the Intel** 
  1752. 80386**, 80486**, or compatible processors. It exploits a rich set of features 
  1753. from previous versions of OS/2, such as support for multitasking, 
  1754. multithreading, dynamic linking, interprocess communication, a graphical user 
  1755. interface, and the High Performance File System.  OS/2 Version 2.0, however, 
  1756. provides significant enhancements over previous versions of OS/2. 
  1757.  
  1758. The following new features have been implemented in OS/2 Version 2.0: 
  1759.  
  1760.  Support for the Intel 80386 32-bit microprocessor instruction set. 
  1761.  
  1762.  32-bit memory management. 
  1763.  
  1764.  Enhanced hardware exploitation. 
  1765.  
  1766.  Multiple Virtual DOS Machines. 
  1767.  
  1768.  Support for Microsoft Windows applications. 
  1769.  
  1770.  32-bit programming environment. 
  1771.  
  1772.  Object-code compatibility with previous versions of OS/2, allowing 16-bit 
  1773.   applications written for previous versions to execute under Version 2.0 
  1774.   without modification. 
  1775.  
  1776.  Enhanced Presentation Manager* user shell, which implements the 1991 SAA* CUA 
  1777.   Workplace Environment. 
  1778.  
  1779.  
  1780. ΓòÉΓòÉΓòÉ 11.1.2. Memory and Task Management ΓòÉΓòÉΓòÉ
  1781.  
  1782. The foundation for OS/2 Version 2.0 capabilities is its support for the Intel 
  1783. 80386 microprocessor. This support means that a powerful set of 32-bit features 
  1784. now becomes available to the operating system and applications, including 
  1785. enhanced memory management and more sophisticated multitasking. 
  1786.  
  1787. OS/2 Version 2.0 requires the features of the Intel 80386 or compatible 32-bit 
  1788. microprocessors, and therefore does not run on computers that use the Intel 
  1789. 80286** processor, or its predecessors.  In order to maintain compatibility, 
  1790. however, OS/2 Version 2.0 supports applications written for previous versions 
  1791. of OS/2 by providing both a 16-bit as well as a 32-bit application programming 
  1792. interface, allowing 16-bit applications to execute under OS/2 Version 2.0 
  1793. without modification.  The Intel 80386 can address 4 gigabytes of physical 
  1794. memory and up to 64 terabytes of virtual memory. 
  1795.  
  1796. OS/2 Version 2.0 supports execution of the following types of applications: 
  1797.  
  1798.  DOS applications, in full-screen mode or in window-mode on the Presentation 
  1799.   Manager desktop. 
  1800.  
  1801.  Microsoft Windows applications, in windows on the Presentation Manager 
  1802.   desktop. 
  1803.  
  1804.  16-bit OS/2 applications developed for previous versions of OS/2. 
  1805.  
  1806.  32-bit applications developed for OS/2 Version 2.0. 
  1807.  
  1808. All applications execute as protected mode processes under OS/2 Version 2.0, 
  1809. and are therefore provided with pre-emptive multitasking and full memory 
  1810. protection between processes. 
  1811.  
  1812. Memory management is the way in which the operating system allows applications 
  1813. to access the system's memory.  The operating system must check how much memory 
  1814. is available to an application, and handle the event when there is no longer 
  1815. any real memory left to satisfy an application's requests. 
  1816.  
  1817. In OS/2 Version 2.0, memory management has been enhanced to provide a flat 
  1818. memory model, which takes advantage of the 32-bit addressing scheme provided by 
  1819. the Intel 80386 architecture.  This means that through memory management, the 
  1820. system's memory is seen as one large linear address space of 4GB.  This 32-bit 
  1821. programming environment is free from the limitations and inherent complexity of 
  1822. the segmented memory model used by DOS and previous 16-bit versions of OS/2. 
  1823. Memory management within applications is greatly simplified, allowing 
  1824. applications to be developed faster, with better performance due to reduced 
  1825. memory manipulation overhead.  Through the use of the flat memory model, 
  1826. applications may be more easily ported to or from other operating system 
  1827. platforms. 
  1828.  
  1829. Task Management, the management of processes and threads executing in a system, 
  1830. is greatly simplified and streamlined under OS/2 Version 2.0. This is due 
  1831. primarily to the fact that support for processes executing in real mode (such 
  1832. as the DOS Compatibility Box in previous versions of OS/2) is no longer 
  1833. required, since the execution of DOS applications is supported using virtual 
  1834. DOS machines which run as protected mode processes under OS/2 Version 2.0. 
  1835.  
  1836. Interrupt handling under OS/2 Version 2.0 is simplified by removal of the need 
  1837. to handle real mode software interrupts.  Interrupts issued by DOS and Windows 
  1838. applications are trapped by a virtual programmable interrupt controller (VPIC) 
  1839. which translates the interrupts to the appropriate device access commands for 
  1840. the protected mode environment.  The virtual programmable interrupt controller 
  1841. is described in Device Drivers. 
  1842.  
  1843.  
  1844. ΓòÉΓòÉΓòÉ 11.1.3. User Interface ΓòÉΓòÉΓòÉ
  1845.  
  1846. OS/2 Version 2.0 also provides an enhanced user shell, known as the Workplace 
  1847. Shell*, through enhancements to Presentation Manager.  The Workplace Shell is 
  1848. object-based and implements the 1991 SAA CUA Workplace Environment.  This shell 
  1849. is more intuitive than the Presentation Manager shell implemented in previous 
  1850. versions of OS/2, and allows users to become familiar with the system more 
  1851. quickly. 
  1852.  
  1853. In the Workplace Shell, system resources, such as files and printers, are 
  1854. regarded as objects, and represented by graphical icons on the screen. Users 
  1855. may manipulate objects (open them for editing, copy them, and print them, for 
  1856. example) by direct manipulation of the icons.  For example, a file is copied 
  1857. from one location to another by pointing to it with the mouse, dragging the 
  1858. object's icon to the required destination, and dropping the icon by releasing 
  1859. the mouse button.  This is known as drag and drop manipulation. 
  1860.  
  1861. Presentation Manager and the Workplace Shell are described in more detail in 
  1862. OS/2 Version 2.0 - Volume 3:  Presentation Manager and Workplace Shell. 
  1863.  
  1864.  
  1865. ΓòÉΓòÉΓòÉ 11.2. Multiple Virtual DOS Machines ΓòÉΓòÉΓòÉ
  1866.  
  1867. OS/2 Version 2.0 provides the user with the ability to run multiple concurrent 
  1868. DOS applications, and to multitask these applications with OS/2 applications. 
  1869. In previous versions of OS/2, support for DOS applications was limited to a 
  1870. single DOS session, known as the DOS Compatibility Box, in which the amount of 
  1871. memory available to the DOS application was restricted.  Applications running 
  1872. in the DOS Compatibility Box could operate in full-screen mode only, and were 
  1873. suspended when switched to the background. 
  1874.  
  1875. Support for DOS applications has been completely redesigned in OS/2 Version 
  1876. 2.0, which now provides for the execution and management of multiple concurrent 
  1877. DOS applications, where each application is executed as a single-threaded, 
  1878. protected mode OS/2 program.  This capability is provided by a component of 
  1879. OS/2 Version 2.0 known as Multiple Virtual DOS Machines (MVDM). 
  1880.  
  1881. MVDM introduces powerful DOS application support to OS/2 by exploiting the 
  1882. virtual 8086 (V86) mode of the Intel 80386 processor.  This mode of operation 
  1883. allows the emulation of an Intel 8086 processor and associated hardware devices 
  1884. within a protected mode 80386 task.  OS/2 Version 2.0 uses the virtual 8086 
  1885. mode to allow the creation of multiple instances of independent virtual DOS 
  1886. machines. Through this technique, a virtual interface is provided to each 
  1887. virtual DOS machine, giving the impression that the application running in that 
  1888. machine owns all the required resources, both hardware and software. 
  1889.  
  1890. Each virtual DOS machine runs as a protected mode process, in a manner similar 
  1891. to an OS/2 application.  The use of protected mode allows pre-emptive 
  1892. multitasking of DOS applications and provides a protected system environment in 
  1893. which DOS applications can execute.  This means that system memory and all 
  1894. other applications (both DOS and OS/2), are protected from ill-behaved 
  1895. applications, and the user can terminate a DOS application which is "hung". An 
  1896. errant DOS application can affect only its own virtual DOS machine; other 
  1897. applications in the system will not be affected. 
  1898.  
  1899. Figure "Concurrent DOS Applications under the Workplace Shell" 
  1900.  
  1901. Each virtual DOS machine has a great deal more available memory than did the 
  1902. DOS Compatibility Box implemented in previous versions of OS/2.  Depending on 
  1903. the use of DOS device drivers and TSR programs, it is possible to have as much 
  1904. as 630KB of available memory for application execution.  In addition, OS/2 
  1905. Version 2.0 supports the use of the Lotus**-Intel-Microsoft (LIM) Expanded 
  1906. Memory Specification (EMS) and the Lotus-Intel-Microsoft-AST** (LIMA) Extended 
  1907. Memory Specification (XMS) to provide additional memory for those DOS 
  1908. applications which are capable of using such memory extenders.  OS/2 Version 
  1909. 2.0 maps this expanded or extended memory into the system's linear memory 
  1910. address space, and manages it in the same manner as any other memory. 
  1911.  
  1912. Each virtual DOS machine may run either in full-screen mode or within a 
  1913. Presentation Manager window. A window containing a DOS application may be sized 
  1914. and manipulated in the same manner as any other Presentation Manager window, 
  1915. and other Presentation Manager desktop features are readily available such as 
  1916. the ability to cut/copy/paste information between applications using the 
  1917. clipboard, or the ability to change fonts. 
  1918.  
  1919. From the user's perspective, DOS applications behave exactly like VIO 
  1920. applications.  DOS applications have the following characteristics: 
  1921.  
  1922.  They may run in either full-screen mode or in window-mode. 
  1923.  
  1924.  They can run in the background if doing text screen output. 
  1925.  
  1926.  Windowed DOS applications have all the same system menu controls as do OS/2 
  1927.   windowed applications, including font adjustment and clipboard functions such 
  1928.   as mark, copy and paste. 
  1929.  
  1930. Furthermore, DOS applications under OS/2 Version 2.0 have advantages over VIO 
  1931. applications: 
  1932.  
  1933.  They may be switched between windowed and full-screen while running. 
  1934.  
  1935.  A full-screen graphics-mode DOS application may be switched into a window and 
  1936.   the graphics bitmap will be rendered in the window. This allows the user to 
  1937.   copy graphics to the Presentation Manager clipboard and gives the viewer more 
  1938.   flexibility when running multiple applications. 
  1939.  
  1940.  For single-plane graphics modes (CGA, and VGA 320 x 200), DOS graphics 
  1941.   applications will execute in a window and continue to update while in the 
  1942.   background. 
  1943.  
  1944. The sole restriction for DOS applications running in a virtual DOS machine when 
  1945. compared with VIO applications is that DOS applications in virtual DOS machines 
  1946. cannot be used in process subtrees. That is, VDMs cannot be run as child 
  1947. processes of either an OS/2 session or another VDM session. 
  1948.  
  1949. There are some DOS applications and products that cannot be supported by DOS 
  1950. emulation, due to the nature of the emulation code and the multitasking and 
  1951. protection demands of OS/2 Version 2.0.  Unsupported products/functions 
  1952. include: 
  1953.  
  1954.  DOS applications which have internal DOS structure dependencies, such as 
  1955.   Windows 1.0x and MS/PC Net. 
  1956.  
  1957.  DOS applications which do not work in a multitasking environment, such as 
  1958.   Norton Disk Utilities**, DOS block device drivers, and Fastback**. 
  1959.  
  1960.  DOS network drivers, because DOS emulation uses an implementation different 
  1961.   from DOS to control its I/O.  However, DOS applications running in VDMs may 
  1962.   access network services through the normal OS/2 network driver. 
  1963.  
  1964. Some of these applications may be run under OS/2 Version 2.0 by booting a 
  1965. specific version of DOS in a virtual DOS machine, using the Virtual Machine 
  1966. Boot feature of MVDM.  This feature is described in detail in Virtual Machine 
  1967. Boot. 
  1968.  
  1969. Application compatibility in the virtual DOS machine is also enhanced over 
  1970. previous versions of OS/2.  A virtual DOS machine can be used to execute 
  1971. DOS-based communications applications and other applications which address 
  1972. hardware I/O devices, through the use of virtual device drivers, which map 
  1973. device driver calls from DOS applications to the appropriate physical device 
  1974. driver within the operating system.  Applications using hardware devices which 
  1975. do not have to be shared with DOS applications in the same system may access 
  1976. these devices using the standard DOS device drivers, without the need for a 
  1977. virtual device driver.  Certain restrictions still apply with respect to 
  1978. communications line speed and time-critical interrupt handling. 
  1979.  
  1980. A powerful new feature called DOS Settings allows an individual to easily 
  1981. tailor, via Presentation Manager windows, the resources, such as video and 
  1982. memory, available to an application running in a virtual DOS machine, and thus 
  1983. optimize the way in which a DOS application runs. 
  1984.  
  1985.  
  1986. ΓòÉΓòÉΓòÉ 11.2.1. MVDM Architecture ΓòÉΓòÉΓòÉ
  1987.  
  1988. MVDM is designed to exploit the virtual 8086 (V86) mode of the 80386 processor, 
  1989. which allows operating systems such as OS/2 Version 2.0 to execute multiple DOS 
  1990. applications within the 80386 protected mode environment.  Under OS/2 Version 
  1991. 2.0, each DOS application executes in a virtual DOS machine (VDM), which runs 
  1992. as a single-threaded protected mode process.  The operating system scheduler 
  1993. controls task switching of VDMs in the same way as it does OS/2 application 
  1994. processes. 
  1995.  
  1996. The MVDM kernel controls the state and operation of concurrent VDMs, and is 
  1997. composed of the following four major components as shown in Figure "MVDM 
  1998. Architecture". 
  1999.  
  2000.  1. The Virtual DOS Machine Manager (VDMM) contains the mechanism to start and 
  2001.     interact with DOS applications.  It creates, initializes, and terminates 
  2002.     VDMs.  The VDMM manages system resources such as memory, timers, 
  2003.     semaphores, and files for all VDMs active in the system.  The VDMM is 
  2004.     responsible for loading and initializing all virtual device drivers, in 
  2005.     conjunction with the Virtual Device Driver Manager.  The VDMM is described 
  2006.     in more detail in MVDM Architecture. 
  2007.  
  2008.  2. 8086 Emulation manages communication between 8086 instruction streams and 
  2009.     virtual device drivers.  This emulation performs 8086 instruction decoding, 
  2010.     controls the 80386 processor's I/O Privilege Map for each VDM, manages the 
  2011.     reflection of software interrupts for each VDM, routes IN/OUT instruction 
  2012.     traps to the appropriate virtual device driver, and manages various control 
  2013.     structures required by each virtual device driver.  8086 emulation is 
  2014.     described in more detail in 8086 Emulation. 
  2015.  
  2016.  3. DOS Emulation emulates the function and operation of the DOS operating 
  2017.     system on a per-VDM basis.  Each VDM emulates an entirely independent 
  2018.     instance of DOS.  DOS services are emulated within the MVDM kernel, or by 
  2019.     invoking protected-mode services provided by the OS/2 kernel.  For example, 
  2020.     most DOS file I/O functions are provided by the OS/2 file system.  DOS 5.0 
  2021.     compatibility is provided.  DOS emulation is described in more detail in 
  2022.     MVDM DOS Emulation. 
  2023.  
  2024.  4. The Virtual Device Driver Manager (VDDM) loads, initializes, and 
  2025.     communicates with virtual device drivers.  Virtual device drivers are 
  2026.     required to virtualize the hardware and ROM BIOS, thereby allowing DOS 
  2027.     applications to access hardware devices and BIOS without affecting other 
  2028.     VDMs or other non-V86 mode processes in the system.  The VDDM provides 
  2029.     various system services, known as Virtual Device Helper (VDH) services, to 
  2030.     virtual device drivers.  The Virtual Device Driver Manager is described in 
  2031.     more detail in Device Drivers. 
  2032.  
  2033. These four components interact with one another and with the OS/2 Version 2.0 
  2034. operating system kernel to provide requested services to DOS applications 
  2035. executing in VDMs. 
  2036.  
  2037.  
  2038. ΓòÉΓòÉΓòÉ 11.2.2. Virtual Device Drivers ΓòÉΓòÉΓòÉ
  2039.  
  2040. In order for multiple DOS applications, each running in its own VDM, to access 
  2041. physical hardware devices, each VDM must be provided with a set of "virtual 
  2042. interfaces" to these devices, so that the actions of one application do not 
  2043. affect the state of the device as perceived by applications in other VDMs. 
  2044.  
  2045. Figure "MVDM System Structure Overview" 
  2046.  
  2047. These virtual interfaces are provided by OS/2 Version 2.0 using virtual device 
  2048. drivers. Virtual device drivers are installable modules responsible for 
  2049. virtualizing the hardware and ROM BIOS aspects of the DOS environment for 
  2050. virtual DOS machines.  A virtual device driver manages shared access to 
  2051. hardware I/O devices for multiple VDMs, allowing an application running in a 
  2052. VDM to act as though it exercised sole control over I/O devices.  Virtual 
  2053. device drivers are implemented whenever possible, allowing the BIOS in the 
  2054. system to perform its functions without interference from DOS applications. 
  2055. Virtual device drivers are used to control hardware such as the keyboard, 
  2056. mouse, and serial and parallel ports. 
  2057.  
  2058. Virtual device drivers are responsible for the following functions: 
  2059.  
  2060.  Maintaining a virtual hardware state for each virtual DOS machine (VDM) 
  2061.  
  2062.  Preventing a VDM from corrupting the state of another VDM, or the system as a 
  2063.   whole 
  2064.  
  2065.  Supporting fast screen I/O 
  2066.  
  2067.  Supporting fast communications I/O. 
  2068.  
  2069. The virtual device driver architecture implemented in OS/2 Version 2.0 provides 
  2070. support for all standard hardware utilized by DOS applications and supports 
  2071. installable virtualization, so that new hardware may be added and supported by 
  2072. VDMs without requiring an upgrade to the operating system. 
  2073.  
  2074. Virtual device drivers obtain and release system resources via the Virtual 
  2075. Device Helper (VDH) services, provided by the MVDM kernel.  A virtual device 
  2076. driver typically performs I/O through a physical device driver using a direct 
  2077. call interface.  However, a virtual device driver may directly access an I/O 
  2078. control device.  The virtual video device driver performs such direct access 
  2079. under OS/2 Version 2.0 for performance purposes.  A virtual device driver may 
  2080. also simulate hardware interrupts into one or many VDM processes. 
  2081.  
  2082. Under OS/2 Version 2.0, a virtual device driver is inherently protected from a 
  2083. VDM because it is not visible in the VDM address space, although a virtual 
  2084. device driver must be careful to check all parameters coming in from a VDM to 
  2085. ensure that it does not damage itself or some other part of the system by 
  2086. executing an invalid instruction. 
  2087.  
  2088.  
  2089. ΓòÉΓòÉΓòÉ 11.2.3. Expanded and Extended Memory Support ΓòÉΓòÉΓòÉ
  2090.  
  2091. Many popular DOS applications use EMS (expanded) and/or XMS (extended) memory 
  2092. extenders to gain access to memory in protected mode on the 80286, 80386, or 
  2093. 80486 processors.  These extenders allow DOS applications to access memory 
  2094. above the 1MB real-mode addressing limit, in order to have total code and data 
  2095. space larger than the available base memory, and to have very large code or 
  2096. data objects loaded into memory for enhanced function and performance.  The 
  2097. standard configuration of OS/2 Version 2.0 provides both EMS and XMS functions 
  2098. as part of MVDM. 
  2099.  
  2100. Under MVDM, EMS and XMS memory allocations are managed as OS/2 pageable virtual 
  2101. memory in the same way as any other memory allocated under OS/2 Version 2.0, 
  2102. and not as fixed physical memory as is the case under DOS.  As such, the total 
  2103. expanded/extended memory allocated can exceed the amount of physical memory 
  2104. installed in the system. 
  2105.  
  2106. LIM EMS Version 4.0 Support 
  2107.  
  2108. The LIM (Lotus-Intel-Microsoft) Expanded Memory Specification (EMS) Version 4.0 
  2109. provides a standard interface for the use of expanded memory with Intel 80x86 
  2110. computers.  The specification allows for up to 32MB of expanded memory, with up 
  2111. to 255 expanded memory objects.  Regions within these objects can be mapped 
  2112. into the 8086 address space (below 1MB) as required, allowing DOS applications 
  2113. to access large address spaces. 
  2114.  
  2115. Under OS/2 Version 2.0, EMS emulation provides the following function: 
  2116.  
  2117.  Implements all the required functions in the LIM 4.0 EMS. 
  2118.  
  2119.  Provides each VDM with a logically separate EMS emulation.  Each VDM has its 
  2120.   own set of expanded objects so that features like interprocess communication 
  2121.   work as they would if each VDM were running on a different physical 8086.  A 
  2122.   VDM cannot affect the availability of objects in other VDMs or access 
  2123.   expanded memory "owned" by other VDMs. 
  2124.  
  2125.  Provides for remapping of conventional memory (below 640KB) for use by 
  2126.   programs such as Windows 2.0. 
  2127.  
  2128.  Provides configurable limits for how much expanded memory is available for 
  2129.   all VDMs, as well as a limit per VDM.  An installed program in the start list 
  2130.   allows the user to override the per-VDM limit, subject to the constraints 
  2131.   imposed by the overall limit. 
  2132.  
  2133.  Supports multiple physical to single logical mappings.  Different 8086 
  2134.   addresses can map to the same expanded memory object address. This is 
  2135.   required by programs like Lotus 1-2-3**. 
  2136.  
  2137. EMS emulation is provided in MVDM by the Virtual Expanded Memory Manager 
  2138. (VEMM).  VEMM is a virtual device driver offering a separate EMS emulation for 
  2139. each VDM.  This is accomplished by placing most EMS control structures for a 
  2140. VDM in a per-VDM instance data area outside the V86 application's address 
  2141. space. 
  2142.  
  2143. Unlike most virtual device drivers, VEMM does not have a corresponding physical 
  2144. device driver. Rather, VEMM traps software interrupts for EMS services using a 
  2145. system call and manages the appropriate memory.  VEMM depends upon the memory 
  2146. management capabilities of the OS/2 Version 2.0 operating system kernel. 
  2147. Allocation, reallocation, or deallocation of EMS memory objects is accomplished 
  2148. by requesting corresponding services from VDH services. 
  2149.  
  2150. LIMA XMS Version 2.0 Support 
  2151.  
  2152. The LIMA Extended Memory Specification (XMS) V2.0 provides a standard interface 
  2153. for the use of extended memory on Intel 80286, 80386, and 80486 computers.  XMS 
  2154. functions allow for the moving of code and data objects from base memory into 
  2155. extended memory, and from extended memory to base memory.  Two of the best 
  2156. known programs using XMS functions are print spoolers and virtual disks (RAM 
  2157. disks). 
  2158.  
  2159. The XMS specifications manage three distinct regions of memory: 
  2160.  
  2161.  The High Memory Area (HMA) is located immediately above 1MB and is exactly 
  2162.   65520 bytes (64KB - 16 bytes) in size. 
  2163.  
  2164.  The Upper Memory Area (UMA), consisting of Upper Memory Blocks (UMBs), is 
  2165.   located between 640KB and 1MB. 
  2166.  
  2167.  The Extended Memory Blocks (EMBs) are used only for data storage. 
  2168.  
  2169. Under OS/2 Version 2.0, LIMA XMS emulation provides the following function: 
  2170.  
  2171.  Implements all LIMA V2.0 XMS functions. 
  2172.  
  2173.  Provides each VDM with a separate XMS emulation.  Each VDM has its own high 
  2174.   memory area, upper memory area, and extended memory blocks, so that features 
  2175.   like interprocess communication work as they would if each VDM were running 
  2176.   on a different physical 8086 processor.  VDMs cannot affect the availability 
  2177.   of objects in other VDMs or access memory "owned" by other VDMs. 
  2178.  
  2179.  Provides configurable limits for how much extended memory is available across 
  2180.   all VDMs, as well as a limit per VDM.  An installed program in the start list 
  2181.   can override the per-VDM limit, subject to the constraint given by the 
  2182.   overall limit, and can disable XMS support altogether for a particular VDM if 
  2183.   its installation conflicts with the program being run in the VDM. 
  2184.  
  2185. The Virtual Extended Memory Manager (VXMS) is a virtual device driver that 
  2186. provides a separate XMS emulation for each VDM.  As with VEMM, this is 
  2187. accomplished by placing most VXMS control structures for a VDM in a per-VDM 
  2188. instance data area outside the V86 application's address space.  The amount of 
  2189. memory available to a VDM, the number of handles, and the existence of upper 
  2190. memory blocks are all configurable parameters which may be altered on a per-VDM 
  2191. basis. 
  2192.  
  2193. Like the VEMM virtual device driver, VXMS does not have a corresponding 
  2194. physical device driver, and utilizes the memory management capabilities of the 
  2195. operating system kernel.  XMS object allocation, reallocation and deallocation 
  2196. are accomplished by requesting corresponding services from the memory manager. 
  2197.  
  2198.  
  2199. ΓòÉΓòÉΓòÉ 11.2.4. DOS Settings ΓòÉΓòÉΓòÉ
  2200.  
  2201. MVDM provides the user with the ability to customize the operation of DOS 
  2202. applications via a feature called DOS Settings. This feature allows the user to 
  2203. control special properties which affect the behavior of DOS applications 
  2204. running in a VDM. 
  2205.  
  2206. The DOS Settings feature further enhances the DOS compatibility of a VDM 
  2207. because it allows a user to configure the VDM for DOS applications which might 
  2208. otherwise not work well (or not work at all) with the default settings for a 
  2209. VDM.  The DOS Settings feature also gives the user more control over the 
  2210. consumption of system resources by a DOS application. Help is provided for each 
  2211. setting to assist users in tuning their applications' operation. 
  2212.  
  2213. DOS sessions have many more customizable properties than OS/2 sessions. MVDM 
  2214. provides a common mechanism that supports both a standard complement of 
  2215. settings, and allows virtual device drivers to register custom settings. The 
  2216. standard settings are a subset of the configuration settings available in the 
  2217. CONFIG.SYS file, plus some additional settings required for MVDM. The primary 
  2218. reason for the existence of the option to alter these settings is that DOS 
  2219. applications are typically not careful about consuming system resources, such 
  2220. as memory and processor time.  Hence, MVDM itself must provide a flexible 
  2221. environment for these applications in order to preserve the integrity and 
  2222. performance of the system as a whole. 
  2223.  
  2224. DOS settings are managed on a per-VDM basis and are accessed through 
  2225. Presentation Manager windows.  The dialog boxes presented allow the user to 
  2226. change a setting while the VDM is running.  Only those settings that can be 
  2227. changed for that VDM are presented.  There are many settings which can be 
  2228. tuned.  One parameter, for example, the Idle Detection Threshold, detects idle 
  2229. DOS applications and allows the user to configure the system such that 
  2230. processor time is not wasted by idle DOS applications. 
  2231.  
  2232. Note that while the DOS Settings feature provides significantly enhanced 
  2233. control over the behavior and capabilities of a virtual DOS machine, this level 
  2234. of control is not necessarily obvious to the end user.  Most DOS applications 
  2235. will execute quite satisfactorily with the default VDM settings, and the user 
  2236. is therefore not required to use the DOS Settings feature.  This approach 
  2237. therefore provides the increased functionality without necessarily increasing 
  2238. the complexity of user interaction. 
  2239.  
  2240.  
  2241. ΓòÉΓòÉΓòÉ 11.3. Windows Application Support ΓòÉΓòÉΓòÉ
  2242.  
  2243. OS/2 Version 2.0 provides the capability for Microsoft Windows applications to 
  2244. run under OS/2 Version 2.0.  This support allows applications written for 
  2245. Windows 3.0 and previous versions of Windows (except V1.x) to coexist with OS/2 
  2246. and DOS applications under OS/2 Version 2.0. 
  2247.  
  2248. Each Windows application executes in a virtual DOS machine, and is thus a 
  2249. protected mode process.  As such, Windows applications are subject to the same 
  2250. application protection facilities provided to other protected mode processes 
  2251. under OS/2 Version 2.0.  Windows applications are protected from other Windows 
  2252. applications and from DOS and OS/2 applications executing in the system.  This 
  2253. is in contrast to the native Windows 3.0 environment, where limited protection 
  2254. is provided for Windows 3.0 applications, and none at all for DOS applications 
  2255. unless Windows is running in enhanced mode. 
  2256.  
  2257. The execution of Windows applications as protected mode tasks also allows these 
  2258. applications to take full advantage of the pre-emptive multitasking 
  2259. capabilities of OS/2 Version 2.0, with full pre-emptive multitasking between 
  2260. Windows applications, OS/2 applications, and DOS applications.  This is again 
  2261. in contrast to the native Windows 3.0 environment, where pre-emptive 
  2262. multitasking is available only when Windows 3.0 is running in enhanced mode, 
  2263. thereby impacting performance and preventing many applications written for 
  2264. previous versions of Windows from executing.  OS/2 Version 2.0 has no such 
  2265. restriction. 
  2266.  
  2267. Windows applications running under OS/2 Version 2.0 will run in a mode 
  2268. equivalent to the real or standard modes of Windows 3.0; the enhanced mode of 
  2269. Windows 3.0 is not required since the OS/2 Version 2.0 operating system itself 
  2270. provides equivalent function. 
  2271.  
  2272. Support for Microsoft Windows applications under OS/2 Version 2.0 is discussed 
  2273. in more depth in Windows Applications. 
  2274.  
  2275.  
  2276. ΓòÉΓòÉΓòÉ 11.4. Summary ΓòÉΓòÉΓòÉ
  2277.  
  2278. OS/2 Version 2.0 provides significantly enhanced DOS application support 
  2279. capability over previous versions of OS/2, using a component known as Multiple 
  2280. Virtual DOS Machines.  MVDM offers many significant functions and features, 
  2281. including: 
  2282.  
  2283.  Ability to run multiple DOS sessions concurrently, with full pre-emptive 
  2284.   multitasking and memory protection 
  2285.  
  2286.  Ability to run DOS applications in Presentation Manager windows 
  2287.  
  2288.  Ability to switch between DOS applications via Presentation Manager 
  2289.  
  2290.  High amount of available free memory for DOS applications (630KB and more) 
  2291.  
  2292.  Expanded (EMS) and extended (XMS) memory emulation support 
  2293.  
  2294.  Clipboard support. 
  2295.  
  2296. OS/2 Version 2.0 provides DOS 5.0 compatibility within the virtual 8086 mode of 
  2297. the 80386 processor, and allows execution of multiple concurrent DOS 
  2298. applications, each operating in its own 1MB virtual address space.  This brings 
  2299. true multiprogramming to the DOS environment under OS/2.  A user may run 
  2300. multiple DOS applications in much the same way as they run multiple OS/2 
  2301. applications.  DOS and OS/2 applications can be started in the same ways: 
  2302.  
  2303.  1. From a desktop group window. 
  2304.  2. From the Drives folder. 
  2305.  3. From a command prompt. 
  2306.  4. From the OS/2 START command. 
  2307.  
  2308. The DOS environment is more DOS-compatible than the DOS Compatibility Box 
  2309. implemented under previous versions of OS/2, since OS/2 Version 2.0 
  2310. encapsulates the entire DOS environment in a virtual machine.  This provides 
  2311. better protection for other processes in the system and for the operating 
  2312. system environment itself.  With MVDM, an errant DOS application can only 
  2313. "hang" its own virtual DOS machine, which may then be terminated by the user 
  2314. without affecting other applications in the system. 
  2315.  
  2316. DOS applications may be run full-screen, windowed, or iconized in the 
  2317. background.  Besides being better protected, providing better compatibility and 
  2318. more concurrent DOS applications, the OS/2 Version 2.0 MVDM environment leaves 
  2319. applications with more than 630KB of memory in which to execute. 
  2320.  
  2321. OS/2 Version 2.0 also provides support for the execution of Microsoft Windows 
  2322. applications (written for Windows 3.0 and/or previous versions of Windows, 
  2323. except version 1.0x) to execute under the control of OS/2 Version 2.0.  Each 
  2324. Windows application executes as a separate protected mode task, and is 
  2325. therefore provided with the same pre-emptive multitasking and memory protection 
  2326. as other protected mode tasks under OS/2 Version 2.0. 
  2327.  
  2328. Support for both the Expanded Memory Specification (EMS) and the Extended 
  2329. Memory Specification (XMS) is provided.  DOS asynchronous communications 
  2330. applications can support communication speeds of up to 9600 baud.  Since the 
  2331. DOS environments are swappable, starting many DOS sessions will not increase 
  2332. requirements for more physical (real) memory. 
  2333.  
  2334. The MVDM environment also provides an extendable architecture that allows the 
  2335. environment to be custom tailored to emulate any DOS environment.  The virtual 
  2336. device driver architecture supports this flexible environment.  All of the 
  2337. low-level DOS support, which in previous versions of OS/2 resided in physical 
  2338. device drivers, has been moved into virtual device drivers.  In virtual 8086 
  2339. mode, all interrupt processing is done in protected mode; bimodal device 
  2340. drivers are no longer needed.  The new driver architecture provides physical 
  2341. device drivers for basic device support and virtual device drivers for 
  2342. supporting virtual devices to the DOS environments.  DOS settings allow the 
  2343. user to tailor the functioning of DOS applications in the VDM environment. 
  2344.  
  2345.  
  2346. ΓòÉΓòÉΓòÉ 12. MVDM Architecture ΓòÉΓòÉΓòÉ
  2347.  
  2348. The Multiple Virtual DOS Machines component of OS/2 Version 2.0 is itself 
  2349. comprised of a number of subcomponents, which interact with one another and 
  2350. with the OS/2 Version 2.0 operating system kernel to provide services to DOS 
  2351. applications running in virtual DOS machines. This chapter describes each 
  2352. subcomponent of MVDM, and explains the interaction between subcomponents. 
  2353.  
  2354.  
  2355. ΓòÉΓòÉΓòÉ 12.1. Introduction ΓòÉΓòÉΓòÉ
  2356.  
  2357. OS/2 Version 2.0 is designed to fully exploit the advanced features of the 
  2358. Intel 80386 processor. A major innovation of the 80386 is its support for the 
  2359. execution of multiple 8086 tasks within the 80386 protected mode environment. 
  2360. An 8086 task in this environment is called a virtual 8086 (V86) task. Under 
  2361. OS/2 Version 2.0, V86 tasks are implemented as virtual DOS machines (VDMs), and 
  2362. each runs as a single-threaded, protected mode process. See also Figure "MVDM 
  2363. System Structure Overview". The OS/2 scheduler controls task switching for V86 
  2364. processes in a way similar to the manner in which it controls other OS/2 
  2365. application processes. When a task switch occurs, the VM bit in EFLAGS 
  2366. contained in the V86 process's task state segment indicates the type of the 
  2367. current process. If the VM bit is set, indicating that the process is a VDM, 
  2368. the processor switches to V86 mode. 
  2369.  
  2370. In this area, performance has been improved over previous versions of OS/2, 
  2371. since the processor is never switched to real mode. Switching from protected 
  2372. mode to real mode takes a long time since all CPU register contents must be 
  2373. saved and paging must be disabled before DOS registers are loaded.  Switching 
  2374. to real mode is often accomplished by resetting the CPU, which is very time 
  2375. consuming. The V86 mode of the processor allows the system to run both OS/2 and 
  2376. DOS applications in protected mode. 
  2377.  
  2378. Compared to previous versions of OS/2, DOS applications running in VDMs may: 
  2379.  
  2380.  Run full-screen or in a window 
  2381.  Run in a background session and not be suspended 
  2382.  Use the clipboard 
  2383.  
  2384.    - Copy text 
  2385.    - Copy graphics as bitmaps 
  2386.  
  2387.  Run graphics in full-screen mode 
  2388.  Switch between full-screen and windowed mode 
  2389.  Use LIM EMS Version 4.0 expanded memory services 
  2390.  Use LIMA XMS Version 2.0 extended memory services. 
  2391.  
  2392. Full-screen graphics applications may be switched to windowed mode where the 
  2393. graphics will be displayed as a bitmap. Switching between modes can be done via 
  2394. the system icon menu when in windowed mode. If in full-screen mode, the user 
  2395. must first switch to the Presentation Manager screen group. Selecting Windowed 
  2396. in the menu of the DOS program icon switches the application to windowed mode. 
  2397. To facilitate mode switching, the hot-key combination Alt+Home may be used. 
  2398.  
  2399. While in full-screen mode, the user may copy only the entire contents of the 
  2400. screen to the clipboard. Switching to windowed mode enables the user to copy 
  2401. parts of the screen to the clipboard by selecting areas with the mouse. 
  2402.  
  2403. DOS compatibility is achieved through a combination of hardware and software 
  2404. which ensure the successful execution of DOS applications. Since DOS 
  2405. compatibility is something of a "moving target", MVDM has been architected to 
  2406. provide the maximum possible flexibility. When attempting to ensure the proper 
  2407. execution of a DOS application, typical variable factors to be considered are 
  2408. the hardware and ROM BIOS of the machine, as well as DOS and the application 
  2409. itself. 
  2410.  
  2411.      DOS Operating System
  2412.    + Hardware
  2413.    + DOS Application
  2414.    ----------------------
  2415.    = Compatibility
  2416.  
  2417. The following DOS functions are supported by virtual DOS machines: 
  2418.  
  2419.  All documented DOS system interfaces 
  2420.  
  2421.  Most direct ROM BIOS interfaces 
  2422.  
  2423.  Memory extenders 
  2424.  
  2425.    - LIM EMS Version 4.0 
  2426.    - LIMA XMS Version 2.0 
  2427.  
  2428.  Direct manipulation of common hardware devices. 
  2429.  
  2430. VDMs have certain restrictions: 
  2431.  
  2432.  Single tasking only; no child processes 
  2433.  No active background graphics 
  2434.  No DOS block device drivers; such device drivers are not written for a 
  2435.   multitasking environment, and may compromise the integrity of other VDMs, or 
  2436.   of other processes in the system. 
  2437.  No direct manipulation of hard disk data (that is, bypassing, in this case, 
  2438.   the OS/2 file system); this may also compromise the integrity of other 
  2439.   processes in the system. 
  2440.  No DOS network device drivers, due to differences in the internal 
  2441.   implementation of DOS I/O.  However, DOS applications running in VDMs may 
  2442.   access LAN resources through the normal OS/2 network drivers, and therefore 
  2443.   no function is lost. 
  2444.  
  2445. Figure "MVDM System Structure and Control Flow" provides an overview of the 
  2446. OS/2 Version 2.0 system structure, showing the MVDM kernel and virtual device 
  2447. drivers in relation to key components of the operating system kernel and 
  2448. physical device drivers which provide services to MVDM. 
  2449.  
  2450. Note that virtual device drivers typically access hardware devices through a 
  2451. physical device driver. Direct communication between virtual device drivers and 
  2452. the hardware (as shown in Figure "MVDM System Structure and Control Flow") is 
  2453. used only in exceptional circumstances. One such case is the virtual video 
  2454. device driver, VVIDEO.SYS, which communicates directly with hardware in order 
  2455. to achieve the highest possible level of performance. 
  2456.  
  2457.  
  2458. ΓòÉΓòÉΓòÉ 12.2. Virtual DOS Machine Manager (VDMM) ΓòÉΓòÉΓòÉ
  2459.  
  2460. OS/2 Version 2.0 enables the user to start multiple DOS applications in 
  2461. multiple concurrent VDMs, all of which are controlled by the Virtual DOS 
  2462. Machine Manager (VDMM). 
  2463.  
  2464. Figure "MVDM Protected Mode processes" 
  2465.  
  2466. The VDMM creates a VDM by: 
  2467.  
  2468.  1. Allocating and mapping the required memory 
  2469.  
  2470.  2. Loading and initializing the virtual device drivers required to virtualize 
  2471.     the hardware and ROM BIOS 
  2472.  
  2473.  3. Access to the virtual device helper services and system resources, such as 
  2474.     memory, semaphores, timers, and files, is provided by the VDMM for all 
  2475.     VDMs. 
  2476.  
  2477. Figure "VDM Exception Handling" 
  2478.  
  2479. The VDMM is responsible for handling those 8086 instructions which cannot be 
  2480. executed in V86 mode, such as interrupts. Such instructions cause an exception 
  2481. to be generated by the 80386 processor; this exception is passed to an 
  2482. exception handler within the operating system, which checks the VM bit in the 
  2483. current process's EFLAGs control area. If the VM bit is set, control is passed 
  2484. to the VDMM. The VDMM therefore runs as a protected mode system level process 
  2485. at privilege level 0. 
  2486.  
  2487.  
  2488. ΓòÉΓòÉΓòÉ 12.2.1. VDM Address Space Management ΓòÉΓòÉΓòÉ
  2489.  
  2490. At initialization, each VDM has a linear address space of 4MB, because a single 
  2491. page table is assigned for each VDM. The page table itself is a single 4KB 
  2492. page, and can hold a maximum of 1024 page table entries. Each of these entries 
  2493. is a doubleword and points to a page with a size of 4KB, hence the 4MB size of 
  2494. the initial address space. The size of the address space can be expanded beyond 
  2495. 4MB if required; for instance, an application running in the VDM may request 
  2496. the allocation of a large amount of expanded memory, in which case the VDMM 
  2497. will allocate the memory as needed. 
  2498.  
  2499. Note that when memory is allocated OS/2 V2.0 merely reserves a linear address 
  2500. range. The range is not backed by physical memory until the memory is 
  2501. committed. Memory  may not actually be committed until a later time, and it may 
  2502. be committed in portions. Allocation without commitment does not use any 
  2503. physical memory and therefore does not waste resources. 
  2504.  
  2505. A typical VDM address space map is shown in Figure "Typical VDM Address Space 
  2506. Map". 
  2507.  
  2508. Each VDM task executes in the first megabyte of the linear address space, 
  2509. thereby allowing the physical addresses used within the DOS applications to be 
  2510. mapped directly to the process address space of the VDM. DOS system areas such 
  2511. as the ROM BIOS area and the Interrupt Vector table, are mapped from physical 
  2512. memory into the VDM's address space by the virtual device driver VBIOS.SYS. 
  2513.  
  2514. Page 0 contains, for example, the ROM BIOS area, the Interrupt Vector table, 
  2515. and the DOS communication area. ROM areas used by hardware devices are mapped 
  2516. by the virtual device drivers into the linear address space of the VDM. The 
  2517. same applies to other linear memory objects, such as EMS objects and display 
  2518. memory. 
  2519.  
  2520. A virtual device driver uses the VDHQueryFreePages() device helper service to 
  2521. find a region where no memory in the linear address space has been allocated or 
  2522. mapped. If a free region is found, the VDHReservePages() service is used to 
  2523. reserve the memory region. Mapping cannot take place where memory has already 
  2524. been allocated. On the other hand, memory may not be allocated where mappings 
  2525. already exist. The operating system's memory manager takes care of this. Page 
  2526. faults are generated if a process attempts to access memory which has 
  2527. previously been invalidated because it was unmapped, or if the page has been 
  2528. swapped out to disk. 
  2529.  
  2530. The 64KB memory area above 1MB (also known as the high memory area) must be 
  2531. treated in a special way. This is described in further detail in A20 Line 
  2532. Service (64KB Wraparound) and in High Memory Area (HMA). 
  2533.  
  2534.  
  2535. ΓòÉΓòÉΓòÉ 12.2.2. VDM Creation ΓòÉΓòÉΓòÉ
  2536.  
  2537. A number of tasks are performed when a VDM is initialized. The four main tasks 
  2538. managed by the Virtual DOS Machine Manager are: 
  2539.  
  2540.  1. Task state segment (TSS) initialization 
  2541.  
  2542.  2. Virtual DOS machine process initialization 
  2543.  
  2544.  3. 8086 Emulation initialization 
  2545.  
  2546.  4. DOS Emulation initialization. 
  2547.  
  2548. Task State Segment Initialization 
  2549.  
  2550. The task state segment describes the current machine state, including CPU 
  2551. register contents, and the current software state of a task, such as file 
  2552. descriptors and priority information. The following steps are necessary to 
  2553. initialize the TSS: 
  2554.  
  2555. Figure "VDM Initialization" 
  2556.  
  2557.  1. The VM bit in EFLAGS is set to 1, indicating that the process is a virtual 
  2558.     DOS machine. 
  2559.  
  2560.  2. The IOPL indicator in EFLAGS is set to 3 
  2561.  
  2562.  3. The instruction pointer is set to the task's entry point 
  2563.  
  2564.  4. The code segment (CS) register is set to the linear base address of the 
  2565.     task's initial code segment 
  2566.  
  2567.  5. An LDT is not used in V86 mode, but one must be initialized since interrupt 
  2568.     or exception routines might use an LDT 
  2569.  
  2570.  6. I/O access rights are defined in the I/O permission map. 
  2571.  
  2572. VDM Process Initialization 
  2573.  
  2574. The VDM process initialization is very similar to the creation of a protected 
  2575. mode session: 
  2576.  
  2577.  1. The Per-Task Data Area (PTDA) is created 
  2578.  
  2579.  2. A process slot and a process ID are allocated 
  2580.  
  2581.  3. The operating system's memory manager provides a 4MB linear address space 
  2582.  
  2583.  4. A 4MB global Page Directory Entry, which references the 4MB linear space, 
  2584.     is created 
  2585.  
  2586.  5. The VDM process is started. 
  2587.  
  2588. 8086 Emulation (V86) Initialization 
  2589.  
  2590. The 8086 Emulation initialization then proceeds as follows: 
  2591.  
  2592.  1. The 8086 Emulation code is loaded 
  2593.  
  2594.  2. VDM kernel data is allocated in per-VDM memory below 4MB 
  2595.  
  2596.  3. Virtual device driver instance data is allocated in per-VDM memory below 
  2597.     4MB 
  2598.  
  2599.  4. All known VDM creation hooks (registered by VDHInstallUserHook) are invoked 
  2600.     to initialize virtual device drivers on a per-VDM basis 
  2601.  
  2602.  5. The VEMM (expanded memory) virtual device driver (if used) allocates a 
  2603.     block of memory in a mappable window either between 640KB and 1MB or in the 
  2604.     area between 256KB and RMSIZE (as specified in CONFIG.SYS), and maps it 
  2605.     into the VDM address space. 
  2606.  
  2607. DOS Emulation Initialization 
  2608.  
  2609. The DOS Emulation initialization then proceeds as follows: 
  2610.  
  2611.  1. VDM-related kernel structures are initialized 
  2612.  
  2613.  2. DOS Emulation kernel (DOSKRNL) is loaded 
  2614.  
  2615.  3. Virtual processor mode is started 
  2616.  
  2617.  4. Standard file handles are opened 
  2618.  
  2619.  5. Virtual device driver and DOS device driver "stubs" are initialized 
  2620.  
  2621.  6. DOS device drivers are initialized 
  2622.  
  2623.  7. DOS shell is loaded and executed. 
  2624.  
  2625. DOS Emulation initialization and VDM creation are discussed in greater detail 
  2626. in MVDM DOS Emulation. 
  2627.  
  2628. Once DOS Emulation is complete, the Virtual DOS Machine Manager then issues the 
  2629. VDM_CREATE_DONE event handler to install default I/O hooks, page fault hooks, 
  2630. or INT hooks. Control is then passed to the DOS Emulation kernel to initialize 
  2631. and start the user application program. 
  2632.  
  2633. Once the VDM creation process is complete, the name of the DOS program and 
  2634. other customization parameters are passed to the new VDM. Customization 
  2635. parameters for a specific DOS application can be specified in the Workplace 
  2636. Shell folder in which the name of the DOS program is contained. To change these 
  2637. parameters select the DOS Settings pushbutton. 
  2638.  
  2639. DOS Settings allow the user to tune the VDM environment in which a DOS 
  2640. application runs in order to achieve optimal execution of the program. 
  2641.  
  2642.  
  2643. ΓòÉΓòÉΓòÉ 12.2.3. VDM Termination ΓòÉΓòÉΓòÉ
  2644.  
  2645. A VDM is terminated when the DOS application running within it terminates, or 
  2646. when a virtual device driver terminates the VDM due to some illegal operation. 
  2647. Termination is carried out in the following way: 
  2648.  
  2649.  1. All registered VDM termination hooks are called 
  2650.  
  2651.  2. The 8086 emulation releases all its per-VDM resources 
  2652.  
  2653.  3. The VDMM releases all its per-VDM resources 
  2654.  
  2655.  4. The VDM is destroyed in a way similar to an OS/2 process. 
  2656.  
  2657. The criteria for abnormal termination of a VDM by a virtual device driver are 
  2658. discussed in VDM Termination. 
  2659.  
  2660.  
  2661. ΓòÉΓòÉΓòÉ 12.3. 8086 Emulation ΓòÉΓòÉΓòÉ
  2662.  
  2663. OS/2 Version 2.0 MVDM 8086 Emulation provides "pure" 8086 emulation support for 
  2664. the V86 mode of the Intel 80386 SX and DX processors. [The Intel 80486 SX and 
  2665. DX processors also provide a compatible V86 mode, and are therefore supported 
  2666. by MVDM.] In a native 8086 processor environment, an application can access all 
  2667. available memory up to 1MB and can execute all 8086 processor instructions when 
  2668. running as a single task in an unprotected environment. However, virtual DOS 
  2669. machines run only in protected mode, and an application running in the V86 mode 
  2670. environment therefore has limited access to system memory and cannot execute 
  2671. all CPU instructions; only the OS/2 Version 2.0 operating system itself has 
  2672. full access to memory and the processor. 
  2673.  
  2674. Each VDM runs as a single V86 mode process, emulating all DOS operating system 
  2675. functions and providing a compatible DOS environment unaffected by other VDMs 
  2676. in the system. In the VDM environment, therefore, an application behaves as if 
  2677. it has complete control over system processor and memory resources. In this 
  2678. way, full application function is provided while preserving the integrity of 
  2679. other applications and of the system as a whole. 
  2680.  
  2681. The 8086 Emulation component provides the following: 
  2682.  
  2683.  Software interrupt reflection support 
  2684.  IOPL sensitive instruction emulation support 
  2685.  I/O port trapping 
  2686.  I/O simulation support 
  2687.  Context hook services 
  2688.  Hook software interrupt virtual device driver service 
  2689.  Change VDM execution flow services. 
  2690.  
  2691. 8086 Emulation is described in more detail in 8086 Emulation. 
  2692.  
  2693. Note that the 8086 Emulation component does not provide DOS or 
  2694. hardware-specific emulation. These emulations are provided by the DOS Emulation 
  2695. component (described in more detail below and in MVDM DOS Emulation) and 
  2696. virtual device drivers (described in more detail below and in Device Drivers) 
  2697. respectively. 
  2698.  
  2699.  
  2700. ΓòÉΓòÉΓòÉ 12.4. DOS Emulation ΓòÉΓòÉΓòÉ
  2701.  
  2702. Provision of DOS compatibility requires a combination of hardware, operating 
  2703. system, and application software support. The MVDM DOS Emulation component of 
  2704. OS/2 Version 2.0 addresses only the software aspects of providing DOS 
  2705. compatibility; the VDM Manager, 8086 Emulation and virtual device drivers work 
  2706. together to provide hardware and ROM BIOS compatibility. 
  2707.  
  2708. DOS Emulation provides DOS services to DOS applications running in a virtual 
  2709. DOS machine in such a way as to provide maximum compatibility with the same 
  2710. services provided to DOS applications running under native DOS 5.0. 
  2711.  
  2712. DOS Emulation is implemented by running a very small portion of the DOS 
  2713. Emulation kernel in V86 mode and a much larger portion of code in protected 
  2714. mode outside the VDM. In OS/2 Version 2.0, physical device drivers are loaded 
  2715. above 1MB and only the DOS Emulation kernel resides below 1MB; hence, any 
  2716. user-installed OS/2 device drivers will not affect the amount of application 
  2717. space available to a DOS application running in a VDM. Similarly, adding LAN 
  2718. drivers to the OS/2 configuration to support the network server or redirector 
  2719. functions does not take up DOS application space, even though DOS applications 
  2720. may make use of these network devices. Virtual device drivers are also loaded 
  2721. outside the VDM  address space, and therefore do not reduce the amount of 
  2722. memory available to a DOS application. 
  2723.  
  2724. In this way, the MVDM architecture makes available to DOS applications the 
  2725. maximum amount of memory. In fact, up to 630KB is free for multiple DOS 
  2726. sessions; this represents an increase of about 100KB over memory available to 
  2727. the single DOS session that was available under OS/2 Version 1.3. Note that 
  2728. this amount may be reduced if DOS device drivers and/or TSR programs are loaded 
  2729. in a VDM. 
  2730.  
  2731. DOS Emulation supports all documented DOS interrupts and features. In addition, 
  2732. some undocumented aspects of these functions (especially INT 21h) are supported 
  2733. because a large number of significant DOS applications rely upon these 
  2734. interfaces. 
  2735.  
  2736. DOS Emulation is described in more detail in MVDM DOS Emulation. 
  2737.  
  2738.  
  2739. ΓòÉΓòÉΓòÉ 12.5. Virtual Device Drivers ΓòÉΓòÉΓòÉ
  2740.  
  2741. Virtual device drivers are installable modules responsible for virtualizing the 
  2742. hardware and ROM BIOS aspects of the DOS environment for virtual DOS machines. 
  2743. A virtual device driver manages shared access to hardware I/O devices for 
  2744. multiple VDMs, allowing an application running in a VDM to act as though it 
  2745. exercised sole control over I/O devices. See also Figure "MVDM System Structure 
  2746. Overview". 
  2747.  
  2748. Virtual device drivers are implemented whenever possible, allowing the BIOS in 
  2749. the system to perform its functions without interference from DOS applications. 
  2750. Virtual device drivers are used to control hardware, such as the keyboard, 
  2751. mouse, and serial and parallel ports. 
  2752.  
  2753. The virtual device driver architecture implemented in OS/2 Version 2.0 provides 
  2754. compatible support for all standard hardware utilized by DOS applications and 
  2755. supports installable virtualization, allowing new hardware to be added in the 
  2756. field and supported by VDMs without requiring an upgrade to the operating 
  2757. system. 
  2758.  
  2759. Virtual device drivers are responsible for the following functions: 
  2760.  
  2761.  Maintaining a virtual hardware state for each virtual DOS machine (VDM) 
  2762.  
  2763.  Preventing a VDM from corrupting the state of another VDM, or the system as a 
  2764.   whole 
  2765.  
  2766.  Supporting fast screen I/O 
  2767.  
  2768.  Supporting fast communications I/O. 
  2769.  
  2770. Since DOS may be emulated more than once in OS/2 Version 2.0, virtual device 
  2771. drivers must virtualize the following features to maintain a separate hardware 
  2772. state for each VDM: 
  2773.  
  2774.  ROM BIOS services 
  2775.  Direct manipulation of ROM BIOS data area 
  2776.  Direct manipulation of video RAM 
  2777.  Direct programming of I/O ports 
  2778.  Direct manipulation of device memory 
  2779.  Hardware interrupts 
  2780.  Software interrupts. 
  2781.  
  2782. A virtual device driver typically performs I/O through a physical device 
  2783. driver, using a direct call interface.  However, a virtual device driver may 
  2784. directly access an I/O control device; this technique is used by the virtual 
  2785. video device driver, VVIDEO.SYS, for performance reasons. A virtual device 
  2786. driver may simulate hardware interrupts into one or many VDM processes. 
  2787.  
  2788. Virtual device drivers use a minimal amount of memory. Virtual device drivers 
  2789. do not have to reserve arrays of data structures for each VDM (as did device 
  2790. drivers under previous versions of OS/2). They may be made swappable, so that 
  2791. each device driver does not increase the amount of conventional (or real) 
  2792. memory space consumed. Conventional memory is used only for code and data that 
  2793. must be accessible at hardware interrupt time (for example, when calling a 
  2794. physical device driver). 
  2795.  
  2796. Under OS/2 Version 2.0, a virtual device driver is inherently protected from a 
  2797. VDM because it is not visible in the VDM address space, although the device 
  2798. driver must be careful to check all parameters coming in from a VDM to ensure 
  2799. that it does not damage itself or some other part of the system by executing an 
  2800. invalid instruction. 
  2801.  
  2802. Virtual device drivers obtain and release system resources via the Virtual 
  2803. Device Helper (VDH) services provided by the MVDM kernel. These helper services 
  2804. are accessed via a published programming interface so that manufacturers of 
  2805. hardware devices may develop virtual device drivers for their own devices. 
  2806. Virtual device drivers are installed using the DEVICE= statement in CONFIG.SYS. 
  2807.  
  2808. Note that a virtual device is required only if a device will be shared with 
  2809. other virtual DOS machines. If a particular device is to be used exclusively by 
  2810. one DOS application, a normal DOS device driver (that is, one that is written 
  2811. for DOS) may be used, and a virtual device driver is not required. 
  2812.  
  2813.  
  2814. ΓòÉΓòÉΓòÉ 12.6. VDM Page Faults ΓòÉΓòÉΓòÉ
  2815.  
  2816. A page fault exception may occur in a VDM where a particular page in real 
  2817. memory has been swapped to disk. When a page fault occurs for a linear region 
  2818. which has been initialized as an alias by a virtual device driver, the 
  2819. exception is routed to an exception handler, which has been registered 
  2820. previously by the virtual device driver for the linear address region in which 
  2821. the page fault occurred. The exception handler may cause the page to be loaded 
  2822. or may allow the memory reference to default into a temporary data page, 
  2823. several of which are provided by the MVDM kernel at initialization time. 
  2824.  
  2825. Exception handlers are registered by virtual device drivers at initialization 
  2826. time using the VDHInstallFaultHook() helper function. If no exception handler 
  2827. is registered for the linear region in which the page fault occurred, the page 
  2828. is mapped to temporary data pages in memory. 
  2829.  
  2830. The start address and size of each aliased region, and the exception handler 
  2831. address for each aliased region, is kept in a table, which is set up via the 
  2832. VDHInstallFaultHook() helper service. When a page fault occurs in the VDM 
  2833. address space, this table is searched for a matching region, and the exception 
  2834. handler for that address is called. The page address and the type of fault 
  2835. which occurred are passed to the exception handler. 
  2836.  
  2837.  
  2838. ΓòÉΓòÉΓòÉ 12.7. VDM Window Management ΓòÉΓòÉΓòÉ
  2839.  
  2840. OS/2 Version 2.0 provides for the ability to run a V86 task in a window. The 
  2841. PMShield manages windowed VIO sessions input/output and windowed VDM 
  2842. input/output. 
  2843.  
  2844. The video VDD (Virtual Device Driver) intercepts all I/O instructions to the 
  2845. video adapter, and all screen updates will be redirected/mapped to a logical 
  2846. video buffer (LVB) maintained by the Video VDD. When the Video VDD detects 
  2847. changes in a VDM's video state, it notifies a new PMShield thread, providing it 
  2848. with update information for a specified VDM window. This thread is a 
  2849. high-priority thread that serves the needs of all windowed VDMs. 
  2850.  
  2851. For keyboard and mouse input, the PMShield must simply transform keystroke and 
  2852. mouse event messages into calls to the keyboard and mouse VDDs. 
  2853.  
  2854.  
  2855. ΓòÉΓòÉΓòÉ 12.7.1. Virtual Display Management ΓòÉΓòÉΓòÉ
  2856.  
  2857. Figure "Virtual Display Management" 
  2858.  
  2859. The PMShield is notified by the Video VDD of different changes, which are 
  2860. prioritized, for example "change in video mode", "change in palette", "change 
  2861. in LVB", "scroll of LVB", "string output", "change in cursor", "input 
  2862. notification" when the window scroll has to be adjusted based on the cursor 
  2863. position, "paste notification". 
  2864.  
  2865. Having received notification of one of these changes, it is the PMShield's 
  2866. responsibility to make appropriate changes to the VDM window, usually through 
  2867. the use of one or more PM Graphics Engine call(s). 
  2868.  
  2869. When a windowed VDM is found with a dirty page, the PMShield thread is notified 
  2870. of a LVB change, along with rectangles describing which areas of the VDM's LVB 
  2871. may be dirty. The PMShield finds the smallest rectangle(s) of change, and 
  2872. updates the window using appropriate Graphics Engine services. 
  2873.  
  2874. The PMShield obtains access to the VDM's LVB indirectly, by requesting the 
  2875. Video VDD to copy some rectangular portion of it into a "shield buffer". The 
  2876. PMShield compares the "shield buffer" against a "shadow buffer", which contains 
  2877. the previously displayed contents of the VDM window, to find the smallest areas 
  2878. of change. The roles of the two buffers are then interchanged in preparation 
  2879. for the next update, as it is now the "shield buffer", which contains the last 
  2880. data displayed. 
  2881.  
  2882. If the VDM changes video modes before the PMShield is able to copy the VDM's 
  2883. LVB, an error will be returned to the PMShield on the copy request. The 
  2884. PMShield's action will be to query the new mode and recopy the LVB. 
  2885.  
  2886.  
  2887. ΓòÉΓòÉΓòÉ 12.7.2. Virtual Keyboard Management ΓòÉΓòÉΓòÉ
  2888.  
  2889. Figure "Virtual Keyboard Management" 
  2890.  
  2891. The PMShield transforms keystroke messages into calls to the Keyboard VDD. No 
  2892. buffering by the PMShield is necessary, since the Keyboard VDD already 
  2893. maintains its own virtual keyboard buffer. 
  2894.  
  2895. The only keystrokes that require special handling by the PMShield are those 
  2896. that affect shift states. 
  2897.  
  2898. There are two operations that a VDM can perform on its virtual keyboard: 
  2899.  
  2900.  Change repeat rate 
  2901.  
  2902.  Change shift states. 
  2903.  
  2904. When a VDM changes the repeat rate, whether it is in the foreground, background 
  2905. or windowed at that time, the repeat rate is changed for the whole system. 
  2906. Since the repeat rate is not a per-session attribute under OS/2, the PMShield 
  2907. need not be involved. The shift state information is per-VDM and is managed by 
  2908. the Keyboard VDD, in conjunction with the physical keyboard driver. 
  2909.  
  2910.  
  2911. ΓòÉΓòÉΓòÉ 12.7.3. Virtual Mouse Management ΓòÉΓòÉΓòÉ
  2912.  
  2913. Figure "Virtual Mouse Management" 
  2914.  
  2915. For mouse input, the PMShield will transform mouse event messages into calls to 
  2916. the Mouse VDD. The conversation will require a mapping of the physical mouse 
  2917. position reported by Presentation Manager to a corresponding position within 
  2918. the VDM's screen dimensions. 
  2919.  
  2920. A VDM can change the state of its virtual pointer in various ways: 
  2921.  
  2922.  Change pointer position 
  2923.  
  2924.  Change pointer shape 
  2925.  
  2926.  Change pointer scaling factors. 
  2927.  
  2928. These special changes are of no interest to PMShield. 
  2929.  
  2930.  
  2931. ΓòÉΓòÉΓòÉ 12.8. VDM Interprocess Communication ΓòÉΓòÉΓòÉ
  2932.  
  2933. Communication between processes is valuable in a multitasking operating system 
  2934. to enable concurrent processes to work together.  Pipes are one of three forms 
  2935. within OS/2 of interprocess communication (IPC) and the only form available for 
  2936. IPC from a DOS application running in a VDM to an OS/2 application. 
  2937.  
  2938. This chapter describes how to create, manage, and use named pipes for IPC of a 
  2939. DOS application in a VDM to an OS/2 program. Pipes enable two or more processes 
  2940. to communicate as if they were reading from and writing to a file. 
  2941.  
  2942.  
  2943. ΓòÉΓòÉΓòÉ 12.8.1. About Pipes ΓòÉΓòÉΓòÉ
  2944.  
  2945. A pipe is a named or unnamed buffer used to pass data between processes. A 
  2946. process writes to or reads from a pipe as if the pipe were standard input or 
  2947. standard output.  A parent process can use pipes to control the input that a 
  2948. child process receives and to receive the output that the child process 
  2949. produces. There are two types of pipes - named and unnamed. The only supported 
  2950. pipe to be used between a DOS application in a VDM and an OS/2 program is the 
  2951. named pipe. 
  2952.  
  2953.  
  2954. ΓòÉΓòÉΓòÉ 12.8.2. Named Pipes ΓòÉΓòÉΓòÉ
  2955.  
  2956. Named pipes enable related or unrelated processes on the same computer system 
  2957. or different systems to communicate with each other. Any process that knows the 
  2958. name of a pipe can open and use a named pipe. In addition, named pipe data can 
  2959. be transparently redirected across a network, such as a local area network 
  2960. (LAN). 
  2961.  
  2962. Note:   The current file system implementation for VDMs does not support named 
  2963.         pipes across the LAN. (This limitation will go away with future 
  2964.         versions of OS/2 V2.0). To use named pipes within a VDM and across the 
  2965.         LAN, you would have to boot a real DOS session (see also Virtual 
  2966.         Machine Boot). You would also have to load the LAN Support Program and 
  2967.         the DOS LAN Requestor within such a VMBOOT session. If you do that, 
  2968.         your network adapter will be used by that DOS session exclusively and 
  2969.         cannot be shared with any other session on this machine. 
  2970.  
  2971. One process (server process) creates the pipe and connects to one end of it. 
  2972. Other processes that access the named pipe are called client processes; they 
  2973. connect to the other end of the pipe.  The server and client processes can then 
  2974. pass data back and forth by reading from and writing to the pipe.  The server 
  2975. process controls access to the named pipe. 
  2976.  
  2977. The client process can be either local or remote.  A local client process is 
  2978. one that runs on the same computer system as the server process.  A remote 
  2979. client process runs on a different system and communicates with the server 
  2980. process across a local area network (LAN). 
  2981.  
  2982. The DOS applications running in different VDMs can only work as client 
  2983. processes. The OS/2 application for this kind of IPC has to be the server 
  2984. process. That is because there are no equivalent pipe APIs in DOS to create a 
  2985. named pipe, etc. there are only the standard I/O commands. This means that the 
  2986. DOS client process can read and write from and to the pipe, but it cannot 
  2987. create one.  To do this the DOS client has to know the name of the named pipe 
  2988. to be able to use it like it would use a flat file to open it and process the 
  2989. I/O calls. 
  2990.  
  2991. There is an exercise included in the appendixes that demonstrates a VDM IPC and 
  2992. shows you the sample code (see Lab Session 5: VDM Interprocess Communications 
  2993. for more information). 
  2994.  
  2995.  
  2996. ΓòÉΓòÉΓòÉ 12.9. Summary ΓòÉΓòÉΓòÉ
  2997.  
  2998. MVDM is composed of four major components: 
  2999.  
  3000.  1. The Virtual DOS Machine Manager is responsible for creating and 
  3001.     initializing VDMs. 
  3002.  
  3003.  2. 8086 Emulation provides an emulation of the 8086 hardware environment, 
  3004.     supporting actions such as direct hardware manipulation and hardware 
  3005.     interrupts. 
  3006.  
  3007.  3. DOS Emulation provides an emulation of the DOS operating system 
  3008.     environment, supporting actions such as software interrupts and INT 21h 
  3009.     services. 
  3010.  
  3011.  4. Virtual device drivers provide virtualization of hardware devices, allowing 
  3012.     these devices to appear to a DOS application as though the application has 
  3013.     direct control over the device.  Devices may thus be shared by multiple DOS 
  3014.     applications and/or protected mode (OS/2) applications. 
  3015.  
  3016. These components operate in conjunction with the hardware and the OS/2 Version 
  3017. 2.0 operating system kernel to provide support for DOS applications under OS/2 
  3018. Version 2.0. 
  3019.  
  3020. MVDM allows OS/2 Version 2.0 to exploit the capabilities of the virtual 8086 
  3021. mode of the 80386 processor. MVDM provides the capability to run multiple 
  3022. concurrent DOS applications in virtual DOS machines. Since each VDM is a 
  3023. protected mode task, MVDM provides pre-emptive multitasking and full memory 
  3024. protection for DOS applications, protecting other applications in the system 
  3025. and the operating system itself from interference by an ill-behaved 
  3026. application. Executing VDMs in protected mode (as opposed to real mode) also 
  3027. improves the performance of DOS applications, since the processor is never 
  3028. required to switch to real mode. 
  3029.  
  3030. Each VDM executes in its own 4MB protected mode address space, with the DOS 
  3031. application having access to the lower 1MB of the linear address space. The 
  3032. remainder of the space is occupied by the MVDM code, device drivers, and 
  3033. extended or expanded memory objects. VDMs may run in window or full-screen 
  3034. mode, and a user can dynamically switch between the two. 
  3035.  
  3036. All documented DOS system interfaces, most direct ROM BIOS interfaces, and 
  3037. memory extenders, such as LIM EMS Version 4.0 and LIMA XMS Version 2.0, are 
  3038. supported by the MVDM  architecture. Direct manipulation of common hardware 
  3039. devices is also supported by MVDM. In addition, certain undocumented but 
  3040. commonly used INT 21h services are supported. DOS Emulation provides DOS 5.0 
  3041. compatible support. 
  3042.  
  3043.  
  3044. ΓòÉΓòÉΓòÉ 13. 8086 Emulation ΓòÉΓòÉΓòÉ
  3045.  
  3046. A significant capability of the Intel 80386 and 80486 processor families is 
  3047. their ability to emulate the Intel 8086 processor.  This emulated state is 
  3048. known as virtual 8086 (V86) mode.  The Multiple Virtual DOS Machines component 
  3049. of OS/2 Version 2.0 makes use of this mode to provide emulation of a native DOS 
  3050. environment for applications executing in virtual DOS machines.  The 8086 
  3051. processor hardware emulation is provided by the 8086 Emulation component of 
  3052. MVDM. Other aspects of the DOS environment, such as program loading and 
  3053. execution and device driver support, are provided by the DOS Emulation 
  3054. component, which is described in MVDM DOS Emulation, and by virtual device 
  3055. drivers, described in Device Drivers. 
  3056.  
  3057. This chapter provides an overview of V86 mode, and describes the operation of 
  3058. the 8086 Emulation component. 
  3059.  
  3060.  
  3061. ΓòÉΓòÉΓòÉ 13.1. Virtual 8086 Mode ΓòÉΓòÉΓòÉ
  3062.  
  3063. In a native 8086 environment, the processor does not constrain an application 
  3064. in any way.  The application may access all available memory and execute all 
  3065. processor instructions, since it is running as a single task in an unprotected, 
  3066. real mode environment.  Operating systems and applications written for the 8086 
  3067. (such as DOS) typically take advantage of this freedom to exercise direct 
  3068. control over hardware and system resources. 
  3069.  
  3070. The 80386 processor exhibits its best performance when running in protected 
  3071. mode.  However, in the protected mode environment, applications are restricted 
  3072. to a subset of the system memory and processor instruction set, and real mode 
  3073. applications written for the 8086 processor can violate the protection rules 
  3074. imposed by the processor. 
  3075.  
  3076. The virtual 8086 mode of the 80386 processor allows an operating system to 
  3077. integrate existing applications, written for the 8086 processor, into the 
  3078. protected mode multitasking environment of the 80386, and to execute such 
  3079. applications concurrently with other 8086 applications and protected mode 
  3080. applications. 
  3081.  
  3082. V86 mode tasks execute in the 80386 processor at privilege level 3, and are 
  3083. compatible with the virtual memory and paging facilities of the 80386.  A V86 
  3084. mode task may execute most 8086 instructions, including those which reference 
  3085. memory mapped or I/O mapped devices, or which access the 80386 interrupt enable 
  3086. flag.  These instructions may be executed by the 80386 processor directly, or 
  3087. the 80386 operating system may trap and emulate such instructions. 
  3088.  
  3089. Certain 8086 instructions may not be executed in V86 mode; these include 
  3090. instructions which generate interrupts or exceptions, some of which are not 
  3091. valid in a normal protected mode task.  However, such instructions may be valid 
  3092. for a V86 mode task.  For example, an application running in V86 mode may issue 
  3093. an interrupt 21h operating system call.  An 80386 operating system may register 
  3094. an exception handler to trap and emulate such instructions at a higher 
  3095. privilege level. 
  3096.  
  3097. Figure "VDM Exceptions and Interrupt Handling in a V86 Mode Task" 
  3098.  
  3099. An interrupt or exception in the V86 mode task causes the processor to switch 
  3100. from V86 mode to protected mode.  An exception handler running as a protected 
  3101. mode task at privilege level 0 is then invoked by the 80386 operating system. 
  3102. This handler first determines that the task which issued the interrupt or 
  3103. exception instruction is a valid V86 mode task.  It does this by checking the 
  3104. VM bit in the EFLAGS register.  Two possible states are possible: 
  3105.  
  3106.  If this bit is set, the current task is a V86 mode task.  The exception 
  3107.   handler then invokes a virtual machine monitor. 
  3108.  
  3109.   The virtual machine monitor locates the instruction which caused the 
  3110.   interrupt or exception, decodes the instruction and, if it is a valid 8086 
  3111.   instruction, simulates its execution by invoking appropriate 80386 operating 
  3112.   system services.  If the instruction is not valid (for example, a privileged 
  3113.   80386 instruction), the virtual machine monitor terminates the V86 mode task. 
  3114.  
  3115.  If the bit is not set, the task has issued an illegal instruction, and is 
  3116.   terminated by the virtual machine monitor. 
  3117.  
  3118. Once the instruction which caused the interrupt or exception has been 
  3119. processed, the virtual machine monitor transforms the result into the expected 
  3120. format for the V86 mode task.  It then advances the V86 mode task's EIP 
  3121. (Extended Instruction Pointer) to the next instruction, and issues an IRET 
  3122. instruction which causes the processor to switch back to V86 mode and continue 
  3123. execution of the V86 mode task. 
  3124.  
  3125. The 8086 Emulation component of MVDM is a virtual machine monitor. 
  3126.  
  3127.  
  3128. ΓòÉΓòÉΓòÉ 13.2. DOS Software Interrupt Handling ΓòÉΓòÉΓòÉ
  3129.  
  3130. Upon creation of a VDM, the IOPL field in the EFLAGS register within the VDM 
  3131. process's task state segment is set to 3.  This has two major effects: 
  3132.  
  3133.  It allows the VDM to access the interrupt enable flag (IF), thus permitting 
  3134.   compatibility with DOS applications which temporarily disable interrupts 
  3135.   while performing critical operations. 
  3136.  
  3137.  It means that an interrupt issued from a VDM does not necessarily cause a 
  3138.   general protection exception; certain interrupt handlers may execute at 
  3139.   privilege level 3 within the VDM. 
  3140.  
  3141. If the VDM process is running with IOPL < 3, every interrupt causes a general 
  3142. protection exception; in such cases the operating system would need to 
  3143. virtualize the interrupt at all times, and to emulate all IOPL-sensitive 
  3144. instructions (CLI, STI, LOCK, PUSHF, POPF, INT n, and IRET).  This would result 
  3145. in increased mode switching (between V86 and protected mode) and higher 
  3146. interrupt latency, and would therefore reduce performance. 
  3147.  
  3148. Thus, under OS/2 Version 2.0, a VDM runs with IOPL=3 for maximum performance. 
  3149. Interrupts are virtualized and, where possible, handled within the V86 mode 
  3150. task. 
  3151.  
  3152.  
  3153. ΓòÉΓòÉΓòÉ 13.2.1. Virtualizing Interrupts ΓòÉΓòÉΓòÉ
  3154.  
  3155. The behavior of 8086 Emulation in response to an interrupt is dependent upon 
  3156. the descriptor privilege level (DPL) field for the interrupt handler.  This is 
  3157. shown in Figure "Descriptor Privilege Levels". 
  3158.  
  3159. When a software interrupt occurs in a DOS application running in a VDM, the 
  3160. interrupt is vectored to an interrupt handler determined by an entry in the 
  3161. VDM's Interrupt Vector table.  This interrupt handler has its own descriptor 
  3162. privilege level (DPL).  If the DPL is 3, the interrupt handler code is simply 
  3163. executed, and control returns to the DOS application. 
  3164.  
  3165. If the DPL of the interrupt handler is less than 3, a general protection 
  3166. exception is generated by the processor and passed to the OS/2 Version 2.0 
  3167. kernel.  The general protection exception handler then determines that the 
  3168. exception occurred from a V86 mode task, and invokes 8086 Emulation to simulate 
  3169. execution of the interrupt handler.  Depending upon the type of interrupt, 8086 
  3170. Emulation may perform the emulation within itself, or call another component of 
  3171. MVDM to handle the emulation. 
  3172.  
  3173.  
  3174. ΓòÉΓòÉΓòÉ 13.2.2. Disabling Interrupts ΓòÉΓòÉΓòÉ
  3175.  
  3176. Disabling interrupts from within a DOS application running in a VDM may cause 
  3177. severe problems. If an error or program loop occurs while interrupts are 
  3178. disabled, the condition cannot be handled correctly and the system may crash. 
  3179.  
  3180. To prevent a DOS application running in V86 mode from disabling interrupts for 
  3181. an extended period of time, a hardware timer is provided by the 80386 processor 
  3182. known as the watchdog timer. Such lengthy disabling may cause unrecoverable 
  3183. system errors. The watchdog timer is programmable and generates non-maskable 
  3184. interrupts (NM) after a specified period of time which allow an operating 
  3185. system to detect an errant 8086 application and terminate it. OS/2 Version 2.0 
  3186. provides a hardware interrupt manager. This maintains a time counter for every 
  3187. VDM. All interrupts, except NMI, are checked by this hardware interrupt 
  3188. manager, which resets the time counter with every occurrence of an interrupt 
  3189. for the corresponding VDM. 
  3190.  
  3191. If a counter exceeds a predefined limit (a typical value is 60 milliseconds), 
  3192. interrupts are automatically re-enabled.  The Virtual DOS Machine Manager is 
  3193. notified of the ill-behaved application program, and will then terminate the 
  3194. VDM. 
  3195.  
  3196.  
  3197. ΓòÉΓòÉΓòÉ 13.3. I/O Port Trapping ΓòÉΓòÉΓòÉ
  3198.  
  3199. A DOS application running in a VDM may access I/O ports directly using the 
  3200. normal 8086 I/O instructions (such as, IN and OUT).  These instructions are not 
  3201. considered IOPL-sensitive and do not normally generate a general protection 
  3202. exception;  the operating system checks the I/O privilege map in the VDM's task 
  3203. state segment to determine whether to allow the instruction to execute or to 
  3204. generate a general protection exception.  This allows DOS applications to 
  3205. access hardware devices using the normal DOS device drivers from within a VDM. 
  3206.  
  3207. When access to a device must be shared with other applications, however, a 
  3208. virtual device driver is required, and the VDM may not directly access the I/O 
  3209. port. At initialization time, the virtual device driver issues a call to the 
  3210. VDHSetIOHookState() device helper function, which sets the appropriate bit in 
  3211. the I/O privilege map. 
  3212.  
  3213. When a DOS application subsequently issues an instruction for the I/O port: 
  3214.  
  3215.  1. A general protection exception is generated. 
  3216.  
  3217.  2. The operating system's exception handler routes the exception to 8086 
  3218.     Emulation. 
  3219.  
  3220.  3. 8086 emulation then invokes the virtual device driver. 
  3221.  
  3222.  
  3223. ΓòÉΓòÉΓòÉ 13.4. A20 Line Services (64KB Wraparound) ΓòÉΓòÉΓòÉ
  3224.  
  3225. The region from 1MB to 1MB+64KB is known as the A20 wrap area. Due to the 
  3226. segmented scheme for generating 20-bit physical addresses on an 8088, it is 
  3227. possible for a DOS program to generate physical addresses in the range from 1MB 
  3228. to 1MB + 64KB. On an 8088 system, these addresses wrap to the low 64KB of 
  3229. physical memory. 
  3230.  
  3231. In the 16-bit version of OS/2, OS/2 V1.x, 80286 physical addresses are 24 bits. 
  3232. The twenty-first address line of the 80286 is called the A20 line, and its 
  3233. setting determines whether real-mode programs wrap low physical memory, or 
  3234. directly access the range from 1MB to 1MB + 64KB. When an 80286 is started, the 
  3235. A20 line is disabled, causing the 80286 to emulate the 8088 environment. When 
  3236. the 80286 is switched to protected mode, the A20 line is enabled, since the 
  3237. protected mode of the 80286 generates 24-bit physical addresses. However, the 
  3238. A20 wrap area can be addressed in real mode in OS/2 V1.x if the A20 line is 
  3239. enabled manually. OS/2 V1.x can thus use the memory in the A20 wrap area for 
  3240. bimodal code (for example, OS/2 V1.x device drivers) by managing the state of 
  3241. the A20 line. When running a DOS application in real mode, OS/2 V1.x disables 
  3242. the A20 line to force the 8088 segment wrapping semantics on DOS applications. 
  3243. When accessing bimodal code in the range from 1MB to 1MB + 64KB in real mode, 
  3244. the OS/2 V1.x kernel enables the A20 line. 
  3245.  
  3246. In OS/2 V2.0 however, the area between 1MB and 1MB + 65519 bytes, cannot be 
  3247. accessed by a DOS program in V86 mode using 20 address lines (that is lines 0 
  3248. to 19). For example, addressing 1MB + 1 byte from within a DOS application in 
  3249. V86 mode would access physical memory at address 0;  in other words, the memory 
  3250. addressing would wrap around to access the extra byte of memory.  This is known 
  3251. as wraparound.  Under OS/2 Version 2.0, the addressing of memory beyond 1MB 
  3252. would result in an addressing exception because although address line 20 is 
  3253. activated, it is not valid for a V86 mode process. This is shown in Figure "A20 
  3254. Line Service (64KB Wraparound)". 
  3255.  
  3256. In order to avoid addressing exceptions in OS/2 Version 2.0, the wraparound 
  3257. feature must be simulated with aliased pages. The 1MB V86 address space 
  3258. requires a page table with 256 entries (256 x 4KB = 1MB).  Sixteen additional 
  3259. page table entries are used for the 65519 bytes above 1MB.  These 16 entries 
  3260. are identical to the first 16 entries for the 1MB area, thereby mapping the 
  3261. wraparound area to the address range 0 to 65519. 
  3262.  
  3263. The wraparound feature requires some additional housekeeping by the OS/2 
  3264. Version 2.0 kernel.  When an aliased page is swapped to disk, both page table 
  3265. entries must be flagged as not present. 
  3266.  
  3267.  
  3268. ΓòÉΓòÉΓòÉ 13.5. Summary ΓòÉΓòÉΓòÉ
  3269.  
  3270. The 8086 Emulation component makes use of the virtual 8086 mode of the 80386 
  3271. processor to provide an emulation of the 8086 hardware environment for DOS 
  3272. applications executing in virtual DOS machines.  Application instructions which 
  3273. cause interrupts or which cannot be executed in V86 mode are trapped by the 
  3274. OS/2 Version 2.0 operating system kernel and routed to 8086 Emulation, which 
  3275. may process the instruction within itself or re-route it to the appropriate 
  3276. component of MVDM. 
  3277.  
  3278. For maximum performance, not all interrupts are trapped and routed in this 
  3279. manner.  MVDM makes use of the IOPL field in the VDM process's task state 
  3280. segment, and the Descriptor Privilege Level (DPL) field in the interrupt 
  3281. handler's code segment, to allow certain interrupts to be processed in V86 
  3282. mode.  Only when the interrupt handler must execute at a higher privilege level 
  3283. are the interrupts trapped and routed by the operating system to 8086 
  3284. Emulation.  This improves performance by reducing the number of processor 
  3285. mode-switches required. 
  3286.  
  3287. 8086 Emulation also supports the use of the Intel 8086 64KB wraparound feature, 
  3288. allowing access to the 64KB of memory immediately above the 1MB address line. 
  3289. This capability is used by some DOS software such as the LIMA XMS memory 
  3290. extender, which implements its high memory area (HMA) in this region.  More 
  3291. detailed information regarding HMA can be found in Memory Extender Support. 
  3292.  
  3293.  
  3294. ΓòÉΓòÉΓòÉ 14. MVDM DOS Emulation ΓòÉΓòÉΓòÉ
  3295.  
  3296. MVDM DOS Emulation provides DOS services to applications running in Multiple 
  3297. Virtual DOS Machines. The environment provided is highly compatible with those 
  3298. same services that are provided to DOS applications running under native DOS 
  3299. 5.0. It addresses only DOS compatibility aspects; processor and other hardware 
  3300. aspects of the DOS environment are addressed by the 8086 Emulation component 
  3301. and virtual device drivers. 
  3302.  
  3303. This chapter describes the implementation of the DOS Emulation component, and 
  3304. the DOS software services provided to support DOS applications running in 
  3305. virtual DOS machines. 
  3306.  
  3307.  
  3308. ΓòÉΓòÉΓòÉ 14.1. DOS Emulation Overview ΓòÉΓòÉΓòÉ
  3309.  
  3310. DOS Emulation is implemented by running a very small portion of the DOS 
  3311. Emulation kernel in V86 mode and a much larger portion of this code in 
  3312. protected mode outside the VDM. In OS/2 Version 2.0, physical device drivers 
  3313. are loaded above 1MB and only the DOS Emulation kernel resides below 1MB. Any 
  3314. user-installed OS/2 device drivers will not affect the amount of application 
  3315. space available to a DOS application running in a virtual DOS machine. 
  3316. Similarly, adding LAN drivers to the OS/2 configuration to support a network 
  3317. server or redirector does not impact DOS application space, even though DOS 
  3318. applications may make use of these OS/2 network devices. Virtual device drivers 
  3319. are also loaded outside the VDM  address space, and therefore do not reduce the 
  3320. amount of memory available to a DOS application. 
  3321.  
  3322. In this way, the MVDM architecture makes the maximum amount of memory available 
  3323. to DOS applications. In fact, up to 630KB are free for use by DOS applications; 
  3324. this represents an increase of approximately 100KB over memory available to the 
  3325. single DOS session that was available under OS/2 Version 1.3. Note that this 
  3326. amount may be reduced if DOS device drivers and/or TSR programs are loaded in a 
  3327. VDM. The following DOS features are implemented by the DOS Emulation: 
  3328.  
  3329.  DOS console device driver 
  3330.  DOS device driver loading/support 
  3331.  DOS program loading and execution 
  3332.  DOS FCB I/O support 
  3333.  DOS memory manager 
  3334.  DOS NLS support 
  3335.  DOS PDB process support 
  3336.  VDM entering and exiting kernel mode support 
  3337.  Special DOS compatibility mechanisms. 
  3338.  
  3339. DOS Emulation supports all documented DOS interrupts and features. In addition, 
  3340. some undocumented aspects of these functions (especially INT 21h) are 
  3341. supported. This support is incorporated in the DOS Emulation  component because 
  3342. a large number of popular DOS applications rely upon these interfaces. 
  3343.  
  3344. The following list shows the documented DOS system interrupt services which are 
  3345. implemented by DOS Emulation and which are available to DOS applications 
  3346. running in VDMs: 
  3347.  
  3348. INT 20h               Program terminate interface 
  3349.  
  3350. INT 21h               System call interface 
  3351.  
  3352. INT 22h/INT 23h       Terminate and Ctrl-Break address interfaces 
  3353.  
  3354. INT 24h               Critical error handler interface 
  3355.  
  3356. INT 25h/INT 26h       Absolute disk read/write interfaces 
  3357.  
  3358. INT 27h               Terminate and stay resident (TSR) interface 
  3359.  
  3360. INT 28h               Idle loop interface 
  3361.  
  3362. INT 2Fh               Print spool interface. 
  3363.  
  3364. Other DOS compatibility functions are implemented by the 8086 Emulation 
  3365. component of MVDM, and by virtual device drivers. The functions provided by 
  3366. these components are explained in 8086 Emulation and in Device Drivers, 
  3367. respectively. 
  3368.  
  3369.  
  3370. ΓòÉΓòÉΓòÉ 14.2. DOS Emulation Implementation ΓòÉΓòÉΓòÉ
  3371.  
  3372. A primary design goal for MVDM and the DOS Emulation component was to provide a 
  3373. DOS compatible environment in which a VDM could not negatively affect other 
  3374. VDMs or OS/2 protected mode processes, while at the same time providing the 
  3375. greatest amount of free memory for DOS applications. This goal was achieved by 
  3376. allowing as much of the DOS Emulation  code as possible to execute in protected 
  3377. mode, outside the VDM  address space. This provides improved protection, leaves 
  3378. more memory available for DOS application use, and enhances overall 
  3379. performance. 
  3380.  
  3381.  
  3382. ΓòÉΓòÉΓòÉ 14.2.1. Initialization and VDM Creation ΓòÉΓòÉΓòÉ
  3383.  
  3384. Initialization of the DOS Emulation component is divided into two stages.  The 
  3385. first occurs during OS/2 system initialization. The second stage occurs during 
  3386. creation of each virtual DOS machine. 
  3387.  
  3388. OS/2 Initialization 
  3389.  
  3390. DOS Emulation is involved in OS/2 system initialization because it requires 
  3391. access to information contained in CONFIG.SYS. As the OS/2 initialization 
  3392. procedure processes the CONFIG.SYS file, it records parameters relevant to DOS 
  3393. Emulation. These parameters include those specified in the FCBS and RMSIZE 
  3394. statements, and any DEVICE statements which specify DOS device drivers. These 
  3395. parameters become the default DOS settings for all VDMs. 
  3396.  
  3397. Note:   Virtual device drivers are not loaded or initialized at this stage. 
  3398. Initialization of DOS settings occurs prior to loading virtual device drivers, 
  3399. since these default settings may be required by the device drivers during VDM 
  3400. initialization (creation). 
  3401.  
  3402. VDM Creation Stage 
  3403.  
  3404. Upon creation of a VDM, the Virtual DOS Machine Manager calls the creation-time 
  3405. initialization routines for virtual device drivers and then passes control to 
  3406. the DOS Emulation kernel. At this point, the V86 memory organization appears as 
  3407. shown in Figure "V86 Memory Map Prior to DOS Emulation Initialization". 
  3408.  
  3409. During VDM creation, DOS Emulation performs the following steps: 
  3410.  
  3411.  1. Initialize VDM-Related Kernel Structures 
  3412.  
  3413.     Certain structures in the OS/2 Version 2.0 kernel are initialized in 
  3414.     preparation for processing VDM requests. The System File Table (SFT) 
  3415.     structures, for example, which are used for FCB I/O, are allocated and 
  3416.     initialized. 
  3417.  
  3418.  2. Load DOS Emulation Kernel (DOSKRNL.COM) 
  3419.  
  3420.     The portion of the DOS Emulation kernel which runs in V86 virtual memory is 
  3421.     loaded at the high end of the VDM memory address space. 
  3422.  
  3423.  3. Start Virtual Processor Mode 
  3424.  
  3425.     The protected mode initialization routine returns control to the Virtual 
  3426.     DOS Machine Manager, which then invokes the initialization code within the 
  3427.     V86 mode DOS Emulation kernel. This represents the first transition to V86 
  3428.     mode; at this point, memory is organized as in Figure "V86 Memory Map at 
  3429.     Initial V86 Mode Entry". 
  3430.  
  3431.  4. Open Standard Devices 
  3432.  
  3433.     The initial five file handles (stdin, stdout, stderr, stdaux, and stdprn) 
  3434.     are opened. 
  3435.  
  3436.  5. Initialize Virtual Device Driver DOS Device Driver "stubs" 
  3437.  
  3438.     Some virtual device drivers provide a DOS device driver "stub";  these 
  3439.     stubs are inserted into the V86 address space prior to initialization of 
  3440.     DOS Emulation. As such, this step involves calling the inserted 
  3441.     initialization code and linking the devices into the device chain. Unlike 
  3442.     real DOS device drivers, however, the return from the initialization does 
  3443.     not allow reducing the size of the driver code. See Device Drivers for 
  3444.     further information. 
  3445.  
  3446.  6. Initialize DOS Device Drivers 
  3447.  
  3448.     Each DOS device driver specified in the CONFIG.SYS file is loaded into the 
  3449.     VDM and initialized. Any VDM-specific DOS device drivers passed in the 
  3450.     DosCreateProcess() function call, or configured via the DOS Settings option 
  3451.     DOS Device Drivers, are then loaded and initialized. This is performed one 
  3452.     device driver at a time to allow the device drivers to consume only the 
  3453.     memory that they require or to de-install themselves entirely. As each 
  3454.     device is initialized, it is added to the chain of devices in the VDM. 
  3455.  
  3456.     During initialization, device drivers may issue a limited set of INT 21h 
  3457.     system calls (functions 01h through 0Ch, 25h, 30h, and 35h). This restores 
  3458.     functionality that had been removed from previous versions of OS/2. 
  3459.  
  3460.     Note:   The result is undefined when a DOS device driver issues an INT 21h 
  3461.     system call other than those mentioned above. This is consistent and 
  3462.     compatible with DOS. Issuing an unsupported INT 21h system call will crash 
  3463.     the VDM. 
  3464.  
  3465.     After all device drivers have been initialized, the initialization code is 
  3466.     discarded. 
  3467.  
  3468.  7. Load and Execute DOS Shell 
  3469.  
  3470.     The shell specified in the SHELL command in CONFIG.SYS is loaded, the 
  3471.     initialization code in the V86 address space is discarded, and control is 
  3472.     passed to the shell program. The SHELL specified in CONFIG.SYS can be 
  3473.     overridden in the DosCreateProcess() function call. This is a useful 
  3474.     feature if, for example, a software developer wishes to allow different 
  3475.     versions of COMMAND.COM, for such reasons as alternative national language 
  3476.     support. 
  3477.  
  3478. Upon invocation of the shell program, the VDM's memory map is organized as 
  3479. shown in Figure "V86 Memory Map after Initialization". 
  3480.  
  3481. Before passing control, the Program Descriptor Block (PDB) of the shell is 
  3482. initialized with the command line parameters as specified in CONFIG.SYS. As an 
  3483. extension to the native DOS environment, an additional string is appended after 
  3484. these parameters, separated from the command line string by a NULL byte. This 
  3485. string specifies the drive and directory of the virtual DOS environment after 
  3486. the shell completes its initialization.  This extension provides a default 
  3487. working drive and directory for real mode applications, as is provided for 
  3488. protect mode applications using the Presentation Manager. 
  3489.  
  3490.  
  3491. ΓòÉΓòÉΓòÉ 14.2.2. Requesting System Services ΓòÉΓòÉΓòÉ
  3492.  
  3493. As previously mentioned, MVDM isolates some VDM-specific code and places it 
  3494. into the DOS Emulation kernel in the VDM's address space. This code provides 
  3495. those DOS services which can be supported in V86 mode, such as memory 
  3496. management services. Other services which require protected mode execution are 
  3497. provided by additional code which runs in protected mode. 
  3498.  
  3499. When the DOS Emulation kernel requires protected mode services, it specifies 
  3500. the kernel procedure via an index, and executes a processor instruction which 
  3501. causes a general protection exception. The OS/2 Version 2.0 general protection 
  3502. exception handler traps the exception and invokes the 8086 Emulation component, 
  3503. which in turn transfers control to the specified kernel procedure. This is 
  3504. explained in detail in 8086 Emulation. 
  3505.  
  3506.  
  3507. ΓòÉΓòÉΓòÉ 14.2.3. System Service Call Behavior ΓòÉΓòÉΓòÉ
  3508.  
  3509. DOS system services provided within VDMs are generally compatible with their 
  3510. implementation under DOS 5.0. Some differences do exist, however, and are 
  3511. described below. 
  3512.  
  3513. INT 20h   This service forwards the request to the INT 21h function 00h service 
  3514.           in order to abort the application. 
  3515.  
  3516. INT 21h   All INT 21h services provided in DOS 5.0 are also provided in VDMs. 
  3517.           However, the internal behavior and error processing of some functions 
  3518.           may be different. Where such changes are significant, they are listed 
  3519.           here: 
  3520.  
  3521.     Function 00h (ABORT) 
  3522.  
  3523.      If the CS register does not reference the current PDB, the VDM is 
  3524.      terminated. In certain previous DOS versions, the effect of such a call 
  3525.      was undefined. 
  3526.  
  3527.     FCB Functions 
  3528.  
  3529.      Although OS/2 only provides file I/O access externally through file 
  3530.      handles, it supports these handles internally through the System File 
  3531.      Table (SFT). MVDM allows file handles to be bypassed and SFT entries to be 
  3532.      manipulated directly using a special set of reserved SFT entries, in a 
  3533.      manner similar to previous versions of OS/2. However, since multiple VDMs 
  3534.      are supported, these SFT entries are allocated dynamically upon creation 
  3535.      of a VDM 
  3536.  
  3537.      FCB functions may now be called from device drivers during initialization; 
  3538.      this functionality was not available in previous versions of OS/2. 
  3539.  
  3540.     Function 38h (International) 
  3541.  
  3542.     Function 44h (IOCTL) 
  3543.  
  3544.      IOCTL requests which are destined for device drivers within the VDM are 
  3545.      processed internally. IOCTL requests which are destined for OS/2 device 
  3546.      drivers, however, are treated specially by their respective device 
  3547.      drivers. Such requests may contain pointers to data within the VDM. In 
  3548.      these cases, it is the responsibility of the OS/2 device driver to perform 
  3549.      the necessary translation from V86 virtual addresses into addresses that 
  3550.      are meaningful to the device driver. 
  3551.  
  3552.     Function 5Dh (Internal) 
  3553.  
  3554.       - Subfunction 0Ah (Set Extended Error Information) 
  3555.  
  3556.         This subfunction allows the calling program to set the register values 
  3557.         that are returned from a call to function 59h. This provides 
  3558.         functionality that was not present in previous versions of OS/2. 
  3559.  
  3560.         This subfunction allows terminate and stay resident programs (TSRs) to 
  3561.         save and restore extended error information when they are invoked. 
  3562.  
  3563.     Function 66h - Get/Set Code Page 
  3564.  
  3565.     Function 67h - Set Handle Count 
  3566.  
  3567.      This function restricts the maximum number of open device handles to 254, 
  3568.      including the four standard devices. 
  3569.  
  3570. INT 25h/INT 26h Absolute Disk Read/Write 
  3571.  
  3572.           The read function operates in the same way as in a DOS 5.0 system. 
  3573.           The write function however, is restricted to removable media only, 
  3574.           and reports a hard error on non-removable media. 
  3575.  
  3576.  
  3577. ΓòÉΓòÉΓòÉ 14.2.4. System Callback Procedures ΓòÉΓòÉΓòÉ
  3578.  
  3579. The system callback procedures are "hooks" into DOS (in the case of VDMs, into 
  3580. the DOS Emulation kernel)  which allow application programs to change the 
  3581. default processing action taken for certain system events. These hooks are 
  3582. specified in the V86 mode interrupt vector table as trap service routines. By 
  3583. default, the vectors reference a single IRET instruction if an application does 
  3584. not register its own hook procedure. 
  3585.  
  3586. The vectors used to specify the callback routines are: 
  3587.  
  3588. INT 22h - Terminate Address The DOS Emulation kernel stores the termination 
  3589.           return address at this vector location. 
  3590.  
  3591. INT 23h - Control-C Exit Address The method used to invoke this callback 
  3592.           procedure works the same way as in a DOS 5.0 system. 
  3593.  
  3594. INT 24h - Critical Error Handler Hard errors are normally generated from within 
  3595.           the OS/2 kernel.  When such an error is detected, the file system 
  3596.           checks to see if the requesting task is a VDM. If so, the error 
  3597.           indication is returned to the protected mode portion of DOS 
  3598.           Emulation, which determines if the INT 24h vector has been changed. 
  3599.  
  3600.           If it has not been changed, the normal OS/2 hard error monitor is 
  3601.           called to display the hard error information and to prompt for a 
  3602.           reply.  If it has been changed, the specified critical error handler 
  3603.           is invoked. 
  3604.  
  3605. INT 28h - Idle Loop The method used to call the INT 28h callback routine is 
  3606.           similar to that used in DOS 5.0, but takes into account the fact that 
  3607.           the DOS session is running in a multitasking environment. 
  3608.  
  3609.           The OS/2 scheduler maintains a flag in the VDM address space which 
  3610.           indicates if another process in the system is ready to run. While in 
  3611.           the idle loop, the DOS Emulation kernel repeatedly examines this 
  3612.           flag. If no other OS/2 tasks are ready, the loop proceeds as normal. 
  3613.           If the flag indicates that other tasks are waiting, DOS Emulation 
  3614.           yields control to the operating system, which dispatches the waiting 
  3615.           task. 
  3616.  
  3617. In all other respects, callback procedures operate under MVDM in an identical 
  3618. manner to that experienced under DOS 5.0. 
  3619.  
  3620.  
  3621. ΓòÉΓòÉΓòÉ 14.2.5. VDM Termination ΓòÉΓòÉΓòÉ
  3622.  
  3623. When a VDM is terminated, DOS Emulation closes all handles that have been 
  3624. assigned to all PDB processes within the VDM. All resources associated with 
  3625. open FCBs are also closed. 
  3626.  
  3627. Since the VDM may have been terminated due to an error in a DOS application 
  3628. within the VDM, no data within the VDM is relied upon when closing resources 
  3629. and cleaning up. DOS Emulation explicitly closes both the files and the OS/2 
  3630. devices opened by the VDM. 
  3631.  
  3632.  
  3633. ΓòÉΓòÉΓòÉ 14.2.6. Standard Devices ΓòÉΓòÉΓòÉ
  3634.  
  3635. As in DOS, DOS Emulation includes device drivers for the three "standard" 
  3636. devices, CON, AUX, and PRN. While DOS packages these device drivers in 
  3637. IBMBIO.COM (IO.SYS), DOS Emulation links these into the DOS Emulation kernel 
  3638. (DOSKRNL) to avoid the need for another file. 
  3639.  
  3640. Unlike DOS, the AUX and PRN drivers do not include support for COM1, COM2, 
  3641. LPT1, LPT2, and LPT3. These latter devices are supported directly by the OS/2 
  3642. asynchronous (COM.SYS) and printer (PRINT0n.SYS) device drivers. 
  3643.  
  3644. This approach allows the CON, AUX, and PRN drivers to behave in a highly 
  3645. compatible manner. These drivers issue ROM BIOS calls (INT 10, 14, and 17, 
  3646. respectively) in order to perform their required tasks. At the same time, using 
  3647. the OS/2 device drivers directly for the numbered I/O devices provides higher 
  3648. performance than through the ROM BIOS interfaces, and allows a numbered I/O 
  3649. device to be easily redirected to a remote device on a network, using the 
  3650. underlying OS/2 mechanisms. Hence there is no INT 17 issued when printing on 
  3651. the numbered I/O devices (for example, LPT1, LPT2, etc.) as long as there is 
  3652. only the virtual printer device driver VLPT.SYS installed as the device driver 
  3653. for LPTn devices. If INT 17 is required, for example by a DOS TSR (Terminate 
  3654. and Stay Resident) that intercepts INT 17, the LPTDD.SYS device driver must be 
  3655. installed as well. You can find LPTDD.SYS in the subdirectory \os2\mdos. 
  3656.  
  3657. Note:   Installing LPTDD.SYS will cause printing from a VDM to slow down. 
  3658.  
  3659. Remember that only PRN redirection is supported. This is achieved by the 
  3660. virtual printer device driver VLPT.SYS, which routes INT 17 and direct hardware 
  3661. printing to LPT1, LPT2, or LPT3 using the OS/2 file system.  This is explained 
  3662. in more detail in Device Drivers. 
  3663.  
  3664.  
  3665. ΓòÉΓòÉΓòÉ 14.3. Maximizing VDM Memory ΓòÉΓòÉΓòÉ
  3666.  
  3667. The OS/2 Version 2.0 CONFIG.SYS file specifies the operating system 
  3668. configuration, and installs device drivers and other memory-resident programs. 
  3669. The OS/2 AUTOEXEC.BAT file is specific to the functioning of the VDM 
  3670. environment. More base memory can be made available to programs running in a 
  3671. VDM by removing unnecessary commands from these files. 
  3672.  
  3673.  
  3674. ΓòÉΓòÉΓòÉ 14.3.1. CONFIG.SYS ΓòÉΓòÉΓòÉ
  3675.  
  3676. Virtual device drivers utilized by VDMs consume very little or no memory below 
  3677. the 640KB limit. These device drivers reside outside the V86 mode address 
  3678. space. However, a user may install device drivers that are required by and are 
  3679. specific to certain applications which will run in a VDM. If the commands to 
  3680. load these device drivers (or other memory-resident programs) are added to 
  3681. CONFIG.SYS, these device drivers (or programs) will be loaded into every VDM 
  3682. when it is created, and will reduce the amount of conventional memory available 
  3683. to DOS applications in every VDM. To ensure the maximum amount of memory is 
  3684. available in each VDM, it is recommended that: 
  3685.  
  3686.  DOS device drivers specific to a particular DOS application should be loaded 
  3687.   via the DOS_DEVICE option of DOS Settings. DEVICE= statements for DOS device 
  3688.   drivers should be eliminated from CONFIG.SYS unless the device driver is 
  3689.   required for every VDM. 
  3690.  
  3691.  The number of buffers specified in the Buffers command in CONFIG.SYS should 
  3692.   be minimized. Each buffer consumes about 500 bytes. Be careful to not reduce 
  3693.   this number too much because some programs might not run properly if there 
  3694.   are too few buffers. The default number of buffers is 30; the number should 
  3695.   not be reduced to fewer than 10 or 15 buffers. 
  3696.  
  3697.  If CONFIG.SYS includes the LASTDRIVE command, this should be set to a letter 
  3698.   such as J or K, rather than Z. Each additional drive uses about 100 bytes. 
  3699.  
  3700.  If the CONFIG.SYS file contains an FCBS command, set FCBS to 1. 
  3701.  
  3702. The order of the DEVICE and DEVICEHIGH commands in CONFIG.SYS is important 
  3703. since it can affect both the efficient use of memory and the proper operation 
  3704. of the various programs started from CONFIG.SYS. 
  3705.  
  3706. The CONFIG.SYS statements and options related to VDM operation, and which can 
  3707. be selected during installation, are shown below: 
  3708.  
  3709.  Load the DOS Command Interpreter and load it resident into memory 
  3710.  
  3711.    - SHELL=C:\OS2\MDOS\COMMAND.COM C:\OS2\MDOS /P 
  3712.  
  3713.  Where to load DOS in memory 
  3714.  
  3715.    - DOS=HIGH, UMB 
  3716.  
  3717.  Optional: extended keyboard and display features 
  3718.  
  3719.    - DEVICE=C:\OS2\MDOS\ANSI.SYS 
  3720.  
  3721.  Expanded Memory Manager 
  3722.  
  3723.    - DEVICE=C:\OS2\MDOS\VEMM.SYS 
  3724.  
  3725.  Extended Memory Manager 
  3726.  
  3727.    - DEVICE=C:\OS2\MDOS\VXMS.SYS /UMB 
  3728.  
  3729.  Mouse support 
  3730.  
  3731.    - DEVICE=C:\OS2\MDOS\VMOUSE.SYS 
  3732.  
  3733.  DOS graphics support 
  3734.  
  3735.    - DEVICE=C:\OS2\MDOS\Vxxx.SYS 
  3736.  
  3737.   Where xxx depends on video adapter: 
  3738.  
  3739.    - VCGA.SYS       (if CGA or EGA w/ 64KB) 
  3740.    - VEGA.SYS       (if EGA w/ 128KB) 
  3741.    - VVGA.SYS       (if VGA or 8514) 
  3742.    - V8514.SYS      (if 8514) 
  3743.  
  3744.  Direct I/O serial communication support 
  3745.  
  3746.    - DEVICE=C:\OS2\MDOS\VCOM.SYS 
  3747.  
  3748. The following list shows the order in which device drivers should be specified 
  3749. in CONFIG.SYS: 
  3750.  
  3751.  1. VEMM.SYS 
  3752.  
  3753.  2. Any device drivers that use expanded memory 
  3754.  
  3755.  3. VXMS.SYS 
  3756.  
  3757.  4. Any device drivers that use extended memory 
  3758.  
  3759.  5. Any device drivers that use upper memory blocks. 
  3760.  
  3761. This is the optimal order in which the CONFIG.SYS file should start device 
  3762. drivers. Whether these statements are included at all depends on the amount of 
  3763. memory installed, the hardware configuration, and on the DOS applications to be 
  3764. run. 
  3765.  
  3766.  
  3767. ΓòÉΓòÉΓòÉ 14.3.2. AUTOEXEC.BAT ΓòÉΓòÉΓòÉ
  3768.  
  3769. AUTOEXEC.BAT is specific to the virtual DOS machine environment and has no 
  3770. effect on the OS/2 Version 2.0 operating system. The AUTOEXEC.BAT file starts 
  3771. memory-resident programs, such as network programs, and sets up environment 
  3772. variables.  In addition, the AUTOEXEC.BAT file may also define the command 
  3773. prompt. 
  3774.  
  3775. The default AUTOEXEC.BAT file for all VDMs in OS/2 Version 2.0 is shown in 
  3776. Figure "Default AUTOEXEC.BAT File". 
  3777.  
  3778. In the above AUTOEXEC.BAT file, the LOADHIGH command loads the APPEND TSR into 
  3779. the High Memory Area, thus making available more memory to all DOS applications 
  3780. running in every VDM.  This example assumes that the function performed by the 
  3781. SET COMSPEC command, which is often found in AUTOEXEC.BAT, has been moved to 
  3782. CONFIG.SYS. 
  3783.  
  3784. Note:   In order to maximize the amount of base memory available to 
  3785. applications, any unnecessary commands should be removed from AUTOEXEC.BAT. 
  3786. Commands should only be included in AUTOEXEC.BAT if they are required for every 
  3787. VDM. Commands which are required only for a specific DOS application to be run 
  3788. in a VDM should be placed into a batch file. This batch file should be 
  3789. explicitly entered into the path and file name field of the "parameters field" 
  3790. in the DOS Settings notebook on the "program page" for that specific 
  3791. application. 
  3792.  
  3793.  
  3794. ΓòÉΓòÉΓòÉ 14.4. Command Compatibility ΓòÉΓòÉΓòÉ
  3795.  
  3796. For maximum compatibility, OS/2 Version 2.0 now supports commands previously 
  3797. unique to DOS, including new commands and enhancements recently introduced with 
  3798. IBM DOS 5.0. Commands new to OS/2 Version 2.0 are: 
  3799.  
  3800. MEM               Display memory availability and contents 
  3801. FC                Intelligent file compare utility 
  3802. DOSKEY            Command-line enhancer 
  3803. DEBUG             Program debugger 
  3804. UNDELETE          Recover erased files 
  3805. QBASIC            Enhanced BASIC Interpreter 
  3806.  
  3807. UNDELETE runs in both an OS/2 session and in a VDM. The others run in DOS MVDM 
  3808. mode only. 
  3809.  
  3810. In addition, several enhancements introduced in DOS 5.0 are also supported: 
  3811.  
  3812. DIR               Several new output formatting options 
  3813. ATTRIB            Now supports hidden and system file attributes 
  3814. RESTORE           Option to list backup diskette's contents 
  3815. FIND              Case-insensitive search option 
  3816.  
  3817. These command enhancements are available in both MVDM and OS/2 protect mode. 
  3818.  
  3819. Note:   The following DOS 5.0 enhancements are not provided in OS/2 Version 
  3820. 2.0: 
  3821.  
  3822.  UNFORMAT command 
  3823.  
  3824.  Quick FORMAT 
  3825.  
  3826. A brief summary follows for those unfamiliar with DOS 5.0 enhancements. 
  3827.  
  3828.  
  3829. ΓòÉΓòÉΓòÉ 14.4.1. MEM ΓòÉΓòÉΓòÉ
  3830.  
  3831. MEM displays the amount of used and free memory in the DOS environment.  It 
  3832. lists information about allocated memory areas, free memory areas, and programs 
  3833. that are currently loaded into memory. 
  3834.  
  3835. The format of the MEM command is: 
  3836.  
  3837.     mem [/program | /debug | /classify]
  3838.  
  3839. where: 
  3840.  
  3841. /p(rogram)     displays the status of programs that are currently loaded into 
  3842.                memory. 
  3843. /d(ebug)       displays the status of currently loaded programs, internal 
  3844.                drivers and other programming information. 
  3845. /c(lassify)    displays the status of programs loaded into conventional memory 
  3846.                and the upper memory area. 
  3847.  
  3848. MEM only runs in a DOS session. 
  3849.  
  3850.  
  3851. ΓòÉΓòÉΓòÉ 14.4.2. FC (File Compare) ΓòÉΓòÉΓòÉ
  3852.  
  3853. FC compares two files and displays their differences.  The format of the FC 
  3854. command to compare ASCII (text) files is: 
  3855.  
  3856. FC [/A][/C][/L][/LBn][/N][/T][/W][/n] <file1> <file2>
  3857.  
  3858. FC /B [drive1:][path1] <file1> <file2>
  3859.  
  3860. where: 
  3861.  
  3862. /A        Displays only first and last lines for each set of differences 
  3863. /B        Performs a binary comparison 
  3864. /C        Disregards the case of letters 
  3865. /L        Compares files as ASCII text 
  3866. /LBn      Sets the maximum consecutive mismatches to "n" lines 
  3867. /N        Displays the line numbers on an ASCII comparison 
  3868. /T        Does not expand tabs to spaces 
  3869. /W        Compresses white space (tabs and spaces) for comparison 
  3870. /n        Specifies the number of consecutive lines that must match after a 
  3871.           mismatch 
  3872.  
  3873. Unlike the COMP command, FC attempts to resynchronize after a mismatch.  It 
  3874. recognizes inserted or deleted character sequences, then resumes the 
  3875. comparison. 
  3876.  
  3877.  
  3878. ΓòÉΓòÉΓòÉ 14.4.3. DOSKEY ΓòÉΓòÉΓòÉ
  3879.  
  3880. DOSKEY enhances command line editing, recalls DOS commands, and creates macros. 
  3881. The format of the DOSKEY command is: 
  3882.  
  3883.     doskey [/reinstall] [/bufsize=size] [/macros] [/history]
  3884.         [/insert | /overstrike] [macroname=[text]]
  3885.  
  3886. where: 
  3887.  
  3888. /r(einstall)        installs a new copy of the DOSKEY program 
  3889. /b(ufsize)=size     size of buffer (in bytes) to store commands and macros 
  3890. /m(acros)           displays list of all macros 
  3891. /h(istory)          displays list of all commands stored in memory 
  3892. /i(nsert)|/o(verstrike) selects insert or overtype mode 
  3893.  
  3894. DOSKEY stacks and recalls commands from a LIFO buffer using the up and down 
  3895. cursor keys. The command line can be intuitively edited via left and right 
  3896. cursor keys, with insert and non-destructive backspace.  DOSKEY provides 
  3897. similar command line editing to that of an OS/2 prompt with KEYS=ON specified. 
  3898.  
  3899.  
  3900. ΓòÉΓòÉΓòÉ 14.4.4. DEBUG ΓòÉΓòÉΓòÉ
  3901.  
  3902. DEBUG is used to assist in testing and debugging of executable files.  The 
  3903. format of the DEBUG command is: 
  3904.  
  3905.     debug <filename> [parameters]
  3906.  
  3907. where <filename> is the file to test. 
  3908.  
  3909. parameters are any command line parameters to be passed to the program being 
  3910. debugged, not to DEBUG itself. 
  3911.  
  3912. DEBUG allows the user to examine memory and registers, assemble and disassemble 
  3913. programs, set breakpoints, and step through programs one instruction at a time. 
  3914.  
  3915. Note:   DEBUG supports 8086 and 8087 instructions only. It will not assemble or 
  3916. disassemble 80286/7 or later opcodes, and can only access the low 16 bits of 32 
  3917. bit registers. 
  3918.  
  3919.  
  3920. ΓòÉΓòÉΓòÉ 14.4.5. UNDELETE ΓòÉΓòÉΓòÉ
  3921.  
  3922. The UNDELETE utility recovers files that have been deleted or erased.  When the 
  3923. DEL or ERASE command is issued from any session type, the file is moved to a 
  3924. specified hidden directory, along with details of where the file originated. 
  3925. If no space is available, the oldest files are automatically purged to provide 
  3926. more space. 
  3927.  
  3928. The DELDIR environment variable is used to specify the name and maximum size of 
  3929. the directories where files targeted for deletion are to be stored.  Normally 
  3930. this will be set in CONFIG.SYS, and takes the form: 
  3931.  
  3932.   SET DELDIR = drive:\path, maxsize [;drive:\path, maxsize]
  3933.  
  3934. The string is composed of a directory path specifier and maximum size value for 
  3935. each supported logical drive. These parameters are separated by commas. The 
  3936. definitions for each drive are separated by semicolons. 
  3937.  
  3938. The path portion of the string consists of a drive letter and the fully 
  3939. qualified path of the directory that will be used for storing deleted files. 
  3940.  
  3941. The maxsize portion of the string defines the maximum size of the storage 
  3942. directory, in kilobytes. 
  3943.  
  3944. In order to keep track of deleted files, the system also maintains a control 
  3945. file in each storage directory. 
  3946.  
  3947. When UNDELETE is specified and the file is still recoverable, it is restored to 
  3948. its specified path. If the file already exists, the user is prompted to rename 
  3949. the file, or to skip the current entry. 
  3950.  
  3951. Space occupied by recoverable files is included in DIR and CHKDSK output 
  3952. reports. 
  3953.  
  3954. The format of the UNDELETE command is : 
  3955.  
  3956.   undelete <filename> [/list | /all] [/s] [/force]
  3957.  
  3958. re: 
  3959.  
  3960. <filename>     is the path and name of the file to recover or purge. It may be 
  3961.                wildcarded. 
  3962. /l(ist)        lists deleted files that are available to be recovered without 
  3963.                recovering the files. 
  3964. /a(ll)         recovers all deleted files if they are still present without 
  3965.                prompting for confirmation on each file. 
  3966. /s             include all files in the specified directory and all 
  3967.                subdirectories 
  3968. /f(orce)       removes files so they cannot be recovered. 
  3969.  
  3970. UNDELETE runs in both protect mode and in a DOS VDM. 
  3971.  
  3972.  
  3973. ΓòÉΓòÉΓòÉ 14.4.6. DIR ΓòÉΓòÉΓòÉ
  3974.  
  3975. DIR lists files and subdirectories: New options on the DIR command are: 
  3976.  
  3977. /a attribute Lists only those files with the chosen attribute: 
  3978.  
  3979.    a.  files not yet backed up 
  3980.    h   hidden files 
  3981.    r   read-only files 
  3982.    s   system files 
  3983.    d   directories 
  3984.  
  3985.           attribute may be preceded by a minus sign to select items which do 
  3986.           not have that attribute. 
  3987. /o sortorder Lists items in the chosen order: 
  3988.  
  3989.    n   sorted by name 
  3990.    e   sorted by extension 
  3991.    d   sorted by date 
  3992.    s   sorted by size 
  3993.    g   directories grouped before files 
  3994.  
  3995.           sortorder may be preceded by a minus sign to reverse the output 
  3996.           order. 
  3997. /b        Displays "bare" file information (no date or size) 
  3998. /f        Displays fully qualified file and directory names. 
  3999. /l        Displays output in lowercase letters. 
  4000. /n        Displays the listing in "HPFS" style format. 
  4001. /s        Includes all subdirectories in the search 
  4002.  
  4003. Other enhancements to the DIR command include: 
  4004.  
  4005.  The total byte count of matched files is given 
  4006.  /p (pause) repeats the directory name after each screen is full 
  4007.  /w (wide) distinguishes directory entries from file entries via square 
  4008.   brackets. 
  4009.  
  4010.  
  4011. ΓòÉΓòÉΓòÉ 14.4.7. ATTRIB ΓòÉΓòÉΓòÉ
  4012.  
  4013. ATTRIB now supports manipulation of "hidden" and "system" file attributes. 
  4014.  
  4015. attrib +s <file>    sets the system attribute. 
  4016. attrib -s <file>    clears the system attribute. 
  4017. attrib +h <file>    sets the hidden attribute. 
  4018. attrib -h <file>    clears the hidden attribute. 
  4019.  
  4020. ATTRIB may also be used to set or clear the "Archive" and "Read-only" 
  4021. attributes as before. 
  4022.  
  4023.  
  4024. ΓòÉΓòÉΓòÉ 14.4.8. RESTORE ΓòÉΓòÉΓòÉ
  4025.  
  4026. A new parameter "/d" displays a list of files on the backup diskette which 
  4027. match the file's specified filename, without restoring any files. 
  4028.  
  4029.  
  4030. ΓòÉΓòÉΓòÉ 14.4.9. FIND ΓòÉΓòÉΓòÉ
  4031.  
  4032. A new parameter "/I" will ignore the case of characters when searching for the 
  4033. string. 
  4034.  
  4035.  
  4036. ΓòÉΓòÉΓòÉ 14.5. Summary ΓòÉΓòÉΓòÉ
  4037.  
  4038. The DOS Emulation component provides an emulation of the DOS operating system 
  4039. environment, including DOS features and system services, for applications 
  4040. running in virtual DOS machines. DOS Emulation uses the parameters specified in 
  4041. CONFIG.SYS and virtual device drivers to create an application-compatible DOS 
  4042. environment within the VDM address space. 
  4043.  
  4044. During execution, DOS Emulation receives requests from DOS applications. 
  4045. Depending upon the type of request, it either processes the request itself or 
  4046. causes a general protection exception which results in the request being routed 
  4047. by the operating system kernel to the 8086 Emulation component, which processes 
  4048. the request at a higher privilege level. 
  4049.  
  4050. DOS Emulation also allows DOS applications to hook interrupts, in order to 
  4051. modify the default behavior in response to particular events. This is achieved 
  4052. by providing a virtual interrupt vector table within the V86 mode address 
  4053. space, and routing interrupts through this table. 
  4054.  
  4055. At VDM termination time, DOS Emulation is responsible for closing all files 
  4056. opened by the VDM, and cleaning up the environment to ensure that no devices 
  4057. are still held or memory objects allocated after termination. 
  4058.  
  4059. DOS Emulation also provides support for applications which access the standard 
  4060. devices CON, AUX, and PRN. These devices are emulated within DOS Emulation 
  4061. itself, which processes the interrupts for these devices and returns the 
  4062. results to the DOS application. 
  4063.  
  4064.  
  4065. ΓòÉΓòÉΓòÉ 15. Device Drivers ΓòÉΓòÉΓòÉ
  4066.  
  4067. In order to provide the maximum level of hardware independence for the OS/2 
  4068. Version 2.0 operating system, device driver are used to communicate with 
  4069. hardware devices.  This concept is not new, and has been implemented in 
  4070. previous versions of OS/2 and in the DOS operating system.  However, the 
  4071. implementation of device drivers under OS/2 Version 2.0 differ in several 
  4072. significant ways from that seen in previous versions.  This chapter describes 
  4073. the implementation of device drivers under OS/2 Version 2.0. 
  4074.  
  4075.  
  4076. ΓòÉΓòÉΓòÉ 15.1. Device Driver Architecture ΓòÉΓòÉΓòÉ
  4077.  
  4078. The architecture and structure of a device driver differs considerably, 
  4079. depending on whether the device driver is physical or virtual. 
  4080.  
  4081. OS/2 Version 2.0 makes use of two distinct types of device driver to 
  4082. communicate between the operating system and hardware devices: 
  4083.  
  4084.  Physical device drivers are considered as true device drivers in the sense 
  4085.   that they have a unique and rigid file structure, and interface directly with 
  4086.   the hardware. They operate in protected mode, and are accessed by protected 
  4087.   mode processes and by virtual device drivers. 
  4088.  
  4089.  Virtual device drivers are essentially a dynamic link library conforming to 
  4090.   the EXE32 Load Module format, and generally do not interface directly with 
  4091.   hardware devices. Instead, virtual device drivers are responsible for 
  4092.   presenting a virtual copy of a hardware resource to DOS applications running 
  4093.   in virtual DOS machines, and for coordinating physical access to that 
  4094.   resource. DOS applications typically address hardware devices directly using 
  4095.   interrupts; the virtual device driver allows the VDM environment to appear to 
  4096.   the DOS application as though the application had direct control over the 
  4097.   hardware. Virtual device drivers include a stub which executes in V86 mode 
  4098.   within each VDM, while the main portion of the virtual device driver executes 
  4099.   in protected mode. 
  4100.  
  4101. The relationship between applications, physical and virtual device drivers, and 
  4102. hardware devices is shown in Figure "Physical and Virtual Device Drivers under 
  4103. OS/2 Version 2.0". 
  4104.  
  4105.  
  4106. ΓòÉΓòÉΓòÉ 15.2. Physical Device Drivers ΓòÉΓòÉΓòÉ
  4107.  
  4108. The concept of a device driver is not new to OS/2 Version 2.0; previous 
  4109. versions of OS/2 and DOS have employed device drivers to communicate with 
  4110. hardware devices.  Under previous versions of OS/2, however, many device 
  4111. drivers were required to run in both real mode and protected mode in order to 
  4112. accommodate the requirements of applications running in the DOS Compatibility 
  4113. Box.  This complicated the design of device drivers under previous versions of 
  4114. OS/2, since they were required to be written in a bi-modal manner.  Figure 
  4115. "Structure of Bi-Modal Device Drivers in OS/2 V1.x" shows the structure of 
  4116. bi-modal OS/2 device drivers. MVDM removes the need for real mode device 
  4117. drivers, since DOS applications run in virtual DOS machines, where each VDM is 
  4118. a protected mode task. Real mode device interrupts issued by DOS applications 
  4119. are trapped by the MVDM kernel and routed to device drivers which execute in 
  4120. protected mode. Hence device drivers for OS/2 Version 2.0 need not include real 
  4121. mode sections, and existing device drivers may be updated to remove the real 
  4122. mode components. 
  4123.  
  4124. Physical device drivers communicate directly with hardware devices, and are 
  4125. installed at system initialization time using DEVICE= statements in CONFIG.SYS, 
  4126. as shown in Figure "Physical Device Driver Statements in CONFIG.SYS". 
  4127.  
  4128. The advantage of physical device drivers, as with device drivers in previous 
  4129. versions of OS/2, is that the operating system itself need not be changed if a 
  4130. new hardware device or adapter is installed.  The corresponding device driver 
  4131. may be installed with the device, and used by applications which require access 
  4132. to the device.  The major enhancement in Version 2.0 over previous versions of 
  4133. OS/2 lies in the removal of the real mode component, which simplifies device 
  4134. driver development and improves performance by avoiding the need for processor 
  4135. mode switching. 
  4136.  
  4137.  
  4138. ΓòÉΓòÉΓòÉ 15.3. Virtual Device Drivers ΓòÉΓòÉΓòÉ
  4139.  
  4140. As mentioned previously, DOS applications typically address hardware devices 
  4141. directly using interrupts. This is permissible in a single tasking DOS 
  4142. environment, since it can be safely assumed that the application has complete 
  4143. and exclusive control over the hardware.  However, in the OS/2 Version 2.0 
  4144. environment where multiple applications may be executing concurrently in 
  4145. virtual DOS machines, it is clearly not allowable, since applications could 
  4146. interfere with one another to the detriment of application and system 
  4147. integrity. 
  4148.  
  4149. Multiple DOS applications accessing the same hardware devices from within VDMs 
  4150. require those hardware devices to be virtualized; virtualization implies 
  4151. separate simulation of the physical hardware (I/O ports, device memory, and ROM 
  4152. BIOS) for each virtual DOS machine. This virtualization is accomplished by 
  4153. installable virtual device drivers, which in turn communicate with physical 
  4154. device drivers to address hardware devices. 
  4155.  
  4156. The following virtual device drivers are provided with the OS/2 Version 2.0 
  4157. operating system: 
  4158.  
  4159. VDD            Description 
  4160.  
  4161. VBIOS          ROM BIOS support (1) 
  4162.  
  4163. VCMOS          CMOS data area + Real Time Clock support (1) 
  4164.  
  4165. VDMA           Direct Memory Access (1) 
  4166.  
  4167. VDSK           Disk, only for INT 13 copy-protection (1) 
  4168.  
  4169. VFLPY          Floppy Disk interface (1) 
  4170.  
  4171. VKBD           Keyboard (1) 
  4172.  
  4173. VLPT           Parallel Port Printer (1) 
  4174.  
  4175. VNPX           Numeric Coprocessor Extension (80387) (1) 
  4176.  
  4177. VPIC           Programmable Interrupt Controller (1) 
  4178.  
  4179. VTIMER         Timer (1) 
  4180.  
  4181. VCOM           Asynchronous communication ports 
  4182.  
  4183. VDPMI          DOS Protected Mode Interface 
  4184.  
  4185. VDPX           DOS Protected Mode Extender 
  4186.  
  4187. VXMS           Extended Memory Support 
  4188.  
  4189. VEMM           Expanded Memory Support 
  4190.  
  4191. VWIN           WIN-OS/2 windows 
  4192.  
  4193. VMOUSE         Mouse 
  4194.  
  4195. VCDROM         CD-ROM support 
  4196.  
  4197. VVIDEO         Video (VCGA, VEGA, VMONO, VVGA, VXGA, V8514, VSVGA). 
  4198.  
  4199. These virtual device drivers are described in Standard Virtual Device Drivers. 
  4200. Those indicated with an (1) form the base set of OS/2 V2.0 and are 
  4201. automatically loaded at system initialization time. The others are installed at 
  4202. operating system initialization time, using DEVICE= statements in CONFIG.SYS, 
  4203. as shown in Figure "Virtual Device Driver Statements in CONFIG.SYS". The first 
  4204. two virtual device drivers in Figure "Virtual Device Driver Statements in 
  4205. CONFIG.SYS" communicate with the corresponding physical device drivers from 
  4206. Figure "Physical Device Driver Statements in CONFIG.SYS". 
  4207.  
  4208. Virtual device drivers perform four main functions: 
  4209.  
  4210.  Maintain the hardware state for each VDM 
  4211.  
  4212.  Prevent an application in one VDM from corrupting another VDM 
  4213.  
  4214.  Support fast screen I/O 
  4215.  
  4216.  Support fast communications I/O. 
  4217.  
  4218.  
  4219. ΓòÉΓòÉΓòÉ 15.3.1. Loading Virtual Device Drivers ΓòÉΓòÉΓòÉ
  4220.  
  4221. Virtual device drivers are loaded into memory when the initialization phase of 
  4222. the physical device drivers has completed.  Upon loading, the virtual device 
  4223. driver verifies the communication path to the corresponding physical device 
  4224. driver, and registers hooks with the Virtual DOS Machine Manager for VDM events 
  4225. such as creation, destruction, and foreground/background switching. 
  4226.  
  4227. Upon creation of a VDM, the virtual device driver is notified by the Virtual 
  4228. DOS Machine Manager, and the creation routine of the virtual device driver is 
  4229. invoked.  This causes a stub device driver to be loaded into the VDM's V86 mode 
  4230. address space.  This stub driver accepts device requests from DOS applications 
  4231. within the VDM, and routes them to the virtual device driver outside the V86 
  4232. mode address space. 
  4233.  
  4234. This is typically achieved by having the stub device driver issue an 
  4235. instruction which causes a general protection exception.  This exception is 
  4236. passed to the operating system's general protection exception handler, which in 
  4237. turn passes it to the Virtual DOS Machine Manager, and finally to the 
  4238. appropriate virtual device driver.  The virtual device driver then communicates 
  4239. with the corresponding physical device driver in order to access the hardware 
  4240. device. 
  4241.  
  4242. When a hardware interrupt occurs, the physical device driver is notified and 
  4243. communicates the event to the virtual device driver, which then takes the 
  4244. appropriate action to inform the DOS application.  This occurs even if the VDM 
  4245. is not currently executing in the foreground, since the virtual device driver 
  4246. can access its instance data directly. 
  4247.  
  4248. Note that certain virtual device drivers do not have a corresponding physical 
  4249. device driver.  For example, the VEMM.SYS virtual device driver is used to 
  4250. provide support for the LIM Expanded Memory Specification Version 4.0; this 
  4251. virtual device driver communicates directly with the operating system's memory 
  4252. manager to allocate and manipulate expanded memory objects. 
  4253.  
  4254. Virtual device drivers communicate with the OS/2 Version 2.0 kernel using 
  4255. virtual device helper (VDH) services. The use of these services is required 
  4256. because virtual device drivers execute at privilege level 0, and are thus 
  4257. prevented from issuing normal privilege level 3 function calls to the operating 
  4258. system kernel.  VDH services are also used to communicate with physical device 
  4259. drivers, and for communication between virtual device drivers. 
  4260.  
  4261. Note that there is no fixed communication protocol between a virtual device 
  4262. driver and a physical device driver.  The programmer may use any protocol that 
  4263. suits the needs of the driver.  A shutdown protocol is recommended in case the 
  4264. virtual device driver has to be shut down. 
  4265.  
  4266.  
  4267. ΓòÉΓòÉΓòÉ 15.3.2. Virtual Device Driver Structure ΓòÉΓòÉΓòÉ
  4268.  
  4269. A virtual device driver is a 32-bit EXE file which runs in protected mode and 
  4270. supports the flat memory model.  Figure "Virtual COM and Physical COM Device 
  4271. Drivers" shows the structure of a virtual device driver and the interfaces to a 
  4272. physical device driver. 
  4273.  
  4274. Nearly all virtual device drivers provided in OS/2 V2.0 are written in a 
  4275. high-level language ("C"), although several have portions that were developed 
  4276. using assembler language.  Since software interrupts and hooked I/O port 
  4277. operations cause a trap to privilege level 0, time critical code for these 
  4278. operations should be written in assembler language to achieve the maximum 
  4279. possible performance. 
  4280.  
  4281. A virtual device driver is a 32-bit EXE file that can contain some, all, or 
  4282. none of the following types of objects: 
  4283.  
  4284.  Initialization code 
  4285.  
  4286.  Initialization data 
  4287.  
  4288.  Swappable global code. 
  4289.  
  4290. A virtual device driver must have at least one object of the following types: 
  4291.  
  4292.  Swappable global data 
  4293.  
  4294.  Swappable instance data 
  4295.  
  4296.  Resident global code 
  4297.  
  4298.  Resident global data 
  4299.  
  4300.  Resident instance data. 
  4301.  
  4302. A virtual device driver should contain resident objects for code and data which 
  4303. must be accessed at physical hardware interrupt time, that is, when a physical 
  4304. device driver calls the virtual device driver.  A virtual device driver which 
  4305. does not interact with a physical device driver needs no resident objects. 
  4306. Examples of such device drivers are VEMM and VXMS. 
  4307.  
  4308. A virtual device driver locates its instance data above the 1MB + 64KB line, 
  4309. but below 4MB.  The instance data is therefore outside the VDM's V86 mode 
  4310. address space.  This linear address range is the same for all VDMs; that is, 
  4311. all VDMs have the instance data for a particular virtual device driver at the 
  4312. same linear address.  The offset from the VDM's linear base address to the 
  4313. virtual device driver's instance data is returned by the OS/2 kernel when the 
  4314. device driver is initialized. 
  4315.  
  4316. A virtual device driver may need to access its instance data area at physical 
  4317. hardware interrupt time.  This may be required even when the VDM is not 
  4318. currently executing in the foreground.  Since the instance data is system data 
  4319. located above the V86 addressing range, the virtual device driver may address 
  4320. the per-VDM buffer regardless of which process is currently running.  VDM 
  4321. instance data is accessed by adding the VDM's handle + instance data area 
  4322. offset + data offset within the instance data area. 
  4323.  
  4324. Note that memory objects created by a virtual device driver for passing to a 
  4325. physical device driver must not exceed 64KB in size.  This limitation results 
  4326. from the fact that many physical device drivers are still written using the 
  4327. 16:16 segmented memory model, and cannot therefore support memory objects 
  4328. greater than 64KB in size. 
  4329.  
  4330.  
  4331. ΓòÉΓòÉΓòÉ 15.3.3. ROM BIOS Compatibility ΓòÉΓòÉΓòÉ
  4332.  
  4333. ROM BIOS provides many function calls which are typically used by a DOS 
  4334. application program.  To maintain the virtualization concept and ensure 
  4335. compatibility with applications which access BIOS or its functions, these 
  4336. functions are emulated by a virtual device driver. 
  4337.  
  4338. The VBIOS virtual device driver contains a mechanism to map and initialize the 
  4339. system ROMs (including the ROM and EBIOS data areas) and the interrupt vector 
  4340. table into memory within each virtual DOS machine.  This is done at VDM 
  4341. creation time, before any other virtual device drivers are loaded.  This allows 
  4342. other virtual device drivers to hook interrupt vectors and use VBIOS services. 
  4343. Certain BIOS interfaces are not emulated directly, but are passed to other 
  4344. routines which provide improved performance or functionality.  For example, the 
  4345. video interface routines provided by ROM BIOS are powerful but extremely slow. 
  4346. In order to increase the performance of the video output, the video virtual 
  4347. device driver intercepts the ROM BIOS video interrupt (INT 10h) and performs 
  4348. the requested operations directly, providing improved performance. 
  4349.  
  4350.  
  4351. ΓòÉΓòÉΓòÉ 15.3.4. Hardware Interrupt Simulation ΓòÉΓòÉΓòÉ
  4352.  
  4353. A virtual device driver typically establishes communications with a physical 
  4354. device driver and receives events at hardware interrupt time. Based on the 
  4355. event received from the physical device driver and the VDM's current state, the 
  4356. virtual device driver may need to send a hardware interrupt to the VDM. 
  4357. However, the virtual device driver cannot simply call the VDM's interrupt 
  4358. handler, since the interrupt handler may currently be paged out, and page 
  4359. faults cannot be taken on the VDM's interrupt handler code at hardware 
  4360. interrupt time. 
  4361.  
  4362. The solution is to "simulate" the hardware interrupt to the VDM by delaying it 
  4363. until the VDM process becomes active.  This is done in three steps: 
  4364.  
  4365.  1. The VDM's interrupt request flag for the particular interrupt level (IRQ) 
  4366.     is set, and a global context hook is set to pass control to the virtual 
  4367.     device driver as soon as any VDM becomes active. 
  4368.  
  4369.  2. A VDM context hook is set, which increases the priority of the target VDM, 
  4370.     based on the priority of the interrupt, thereby enabling fast interrupt 
  4371.     processing by the VDM. 
  4372.  
  4373.  3. When the VDM is scheduled and the interrupt request flag is noted, the 
  4374.     VDM's interrupt handler code is invoked. 
  4375.  
  4376. The VDM's interrupt handler typically issues a request for the interrupt data 
  4377. or an EOI instruction.  When the virtual device driver receives either of 
  4378. these, it calls the VDHClearVIRR() helper service to clear the interrupt 
  4379. request flag. If the interrupt request flag is not cleared before the VDM 
  4380. issues an EOI instruction, the virtual device driver immediately simulates 
  4381. another interrupt to the VDM.  For example, the virtual timer device driver may 
  4382. leave the interrupt request flag set when it receives the EOI from a previously 
  4383. simulated interrupt, if it has another hardware timer interrupt pending for 
  4384. that VDM. 
  4385.  
  4386. Clearing Interrupts 
  4387.  
  4388. Note that a virtual device driver must call the VDHClearVIRR() helper service 
  4389. when the VDM issues an EOI instruction.  Otherwise, the application may receive 
  4390. spurious interrupts because the interrupt request flag is not cleared.  For 
  4391. this reason, unknown device interrupts are not supported for VDMs, since there 
  4392. is typically no virtual device driver to clear the interrupt request flag. 
  4393.  
  4394. Interrupts must be simulated to VDMs as quickly as possible.  It is not 
  4395. advisable for a virtual device driver to have too many interrupts pending since 
  4396. the physical device driver's buffers may overflow. 
  4397.  
  4398. A virtual device must also be very careful when it simulates an interrupt to a 
  4399. VDM because too many nested interrupts may cause the application's stack to 
  4400. overflow.  A virtual device driver should wait until the IRET instruction has 
  4401. been executed in the VDM's interrupt handler before it simulates the next 
  4402. interrupt; the virtual device driver may gain control immediately upon IRET 
  4403. being issued, via an IRET handler registered using the VDHOpenVIRQ() helper 
  4404. service. 
  4405.  
  4406. Shared Interrupts 
  4407.  
  4408. Personal System/2 machines equipped with the IBM Micro Channel* bus 
  4409. architecture support multiple hardware devices on the same IRQ level. Hence, 
  4410. support may also be required for virtual device drivers to share interrupts. 
  4411. This support is provided through the VDHOpenVIRQ() helper function, which 
  4412. accepts a flag indicating that a virtual device driver is willing to share its 
  4413. IRQ.  Note that all virtual device drivers using the same IRQ must pass the 
  4414. sharing flag; otherwise, an error is returned. 
  4415.  
  4416. Each virtual device driver receives an IRQ handle, which points to an IRQ data 
  4417. block specific to that device driver.  Data not specific to the virtual device 
  4418. driver is contained in a shared IRQ data structure. 
  4419.  
  4420. When an interrupt is received for a VDM, the virtual interrupt request flag is 
  4421. set and a device request mask is updated.  This device request mask is specific 
  4422. to each VDM, and contains a bit for every virtual device driver which has 
  4423. requested a virtual interrupt for the IRQ.  When the interrupt is cleared, the 
  4424. device mask bit for the virtual device driver is cleared.  However, the virtual 
  4425. interrupt request flag is not cleared until all virtual device drivers have 
  4426. cleared the interrupt. 
  4427.  
  4428. Note that EOI and IRET handler routines are called when the device mask bit is 
  4429. cleared, allowing virtual device drivers to perform correct interrupt 
  4430. termination handling. 
  4431.  
  4432.  
  4433. ΓòÉΓòÉΓòÉ 15.3.5. Protection ΓòÉΓòÉΓòÉ
  4434.  
  4435. An application within a VDM cannot corrupt or destroy a virtual device driver, 
  4436. since the virtual device driver operates in protected mode outside the V86 mode 
  4437. address space, and is thus not accessible by the application. However, the 
  4438. parameters passed to a virtual device driver from the VDM must be carefully 
  4439. checked before being acted upon, in order to ensure that the service request is 
  4440. valid.  Failure to do so may result in failure of a virtual device driver due 
  4441. to an invalid instruction or invalid data. 
  4442.  
  4443. System registers must not be modified by a virtual device driver.  Only certain 
  4444. flags may be modified. These are as follows: 
  4445.  
  4446.  Arithmetic bits 
  4447.  Interrupt bit; note that this must be handled with extreme care 
  4448.  Direction bit. 
  4449.  
  4450. Failure to observe these rules by a virtual device driver may result in failure 
  4451. of the VDM's parent process, and possible corruption of the virtual device 
  4452. driver itself. 
  4453.  
  4454.  
  4455. ΓòÉΓòÉΓòÉ 15.4. Standard Virtual Device Drivers ΓòÉΓòÉΓòÉ
  4456.  
  4457. The following pages provide brief descriptions of each of the standard virtual 
  4458. device drivers provided with the OS/2 Version 2.0 operating system. 
  4459.  
  4460.  
  4461. ΓòÉΓòÉΓòÉ 15.4.1. VBIOS Device Driver ΓòÉΓòÉΓòÉ
  4462.  
  4463. The VBIOS virtual device driver is like any other base virtual device driver 
  4464. except that it is loaded before any other virtual device drivers.  This driver 
  4465. is loaded and initialized first, so that other virtual device drivers can use 
  4466. services provided by VBIOS. 
  4467.  
  4468. The system BIOS reserves physical memory for the interrupt vector table, ROM 
  4469. and EBIOS data areas.  This reservation is done by an indication in the arena 
  4470. info data structure passed to the kernel. These physical pages are treated as 
  4471. "unavailable" by the virtual memory manager. 
  4472.  
  4473. During virtual device driver initialization, the physical interrupt vector 
  4474. table and ROM data area (previously allocated/reserved by the BIOS) are mapped 
  4475. with the VDHMapMem() function.  VBIOS also installs hooks which cause its own 
  4476. VDM creation handler to be invoked, and an I/O hooking routine to be invoked 
  4477. when all virtual device drivers have been initialized for a particular VDM. 
  4478.  
  4479. Space is also reserved for the EBIOS data area (if the machine is a PS/2) and 
  4480. the system ROM linear address ranges.  This allows virtual device drivers to 
  4481. use and modify this information globally (affecting all VDMs created 
  4482. thereafter). 
  4483.  
  4484. The following steps are taken when initializing the BIOS for a newly created 
  4485. VDM: 
  4486.  
  4487.  1. Map the CBIOS system area to the VDM address space, using the VDHMapMem() 
  4488.     service. 
  4489.  2. Allocate memory for the interrupt vector table and ROM BIOS data area. 
  4490.  3. Map and copy the physical interrupt vector table and ROM BIOS data area 
  4491.     into the VDMs linear address space. 
  4492.  4. Allocate memory for the extended BIOS data area in the VDM's linear address 
  4493.     space (only on PS/2s). 
  4494.  5. Map and copy the physical extended BIOS data area into the linear address 
  4495.     space. 
  4496.  
  4497. When VBIOS's VDM_CREATE_DONE handler is called (after all virtual device 
  4498. drivers' VDM_CREATE handlers have been invoked), VBIOS attempts to install I/O 
  4499. hook routines for the serial and parallel ports COMx and LPTx.  These hook 
  4500. routines will take effect only if the virtual COM device driver or the virtual 
  4501. printer device driver have not successfully hooked the I/O ports. VBIOS I/O 
  4502. hook routines are used only to display pop-up messages when the device is not 
  4503. virtualized, and to terminate the VDM on user request. 
  4504.  
  4505.  
  4506. ΓòÉΓòÉΓòÉ 15.4.2. Virtual CMOS Device Driver ΓòÉΓòÉΓòÉ
  4507.  
  4508. The virtual CMOS device driver VCMOS.SYS provides support for virtualization of 
  4509. the CMOS battery backed-up RAM, the real time clock (RTC) and the non-maskable 
  4510. interrupt (NMI) disable logic. It provides virtual access to CMOS addresses and 
  4511. data latches through virtual I/O ports. 
  4512.  
  4513. CMOS Memory Access 
  4514.  
  4515. The CMOS portion of the CMOS/RTC may be read or written.  Virtual CMOS memory 
  4516. is initialized to the contents of the physical CMOS memory upon VDM 
  4517. initialization.  Values written to CMOS memory by DOS applications are written 
  4518. in a buffer local to the VDM.  Unlike the physical CMOS memory, however, the 
  4519. contents of the virtual CMOS buffer are lost when the VDM is terminated. 
  4520.  
  4521. I/O Port Support 
  4522.  
  4523. The virtual CMOS device driver component monitors all accesses to its two VDM 
  4524. I/O ports.  The two ports are a write-only address latch and a read/write data 
  4525. latch.  The address latch port has two functions: 
  4526.  
  4527.  NMI disable 
  4528.  
  4529.  CMOS/RTC device address selection. 
  4530.  
  4531. The data latch is a register for holding a byte being transferred to or from 
  4532. the CMOS/RTC device. 
  4533.  
  4534. NMI Disable 
  4535.  
  4536. The NMI-disable portion of the address latch may be set or reset by a DOS 
  4537. application, but changes to enable or disable NMI are otherwise ignored by 
  4538. VCMOS. 
  4539.  
  4540. Real Time Clock and Interrupt Access 
  4541.  
  4542. The real time clock consists of a time-of-day clock, an alarm interrupt, and a 
  4543. periodic interrupt.  Accesses to the real time clock to change the time of day, 
  4544. the timing mode or to set an alarm or periodic interrupt are disallowed.  Thus, 
  4545. the CMOS/RTC registers related to the real time clock are supported for 
  4546. read-only access. 
  4547.  
  4548. Since interrupts can only be supported through write access to the ports, real 
  4549. time clock interrupts are not supported by VCMOS. 
  4550.  
  4551.  
  4552. ΓòÉΓòÉΓòÉ 15.4.3. Virtual DMA Device Driver ΓòÉΓòÉΓòÉ
  4553.  
  4554. The PC AT has eight DMA channels, each of which can be hard-wired to a slave 
  4555. device on the bus.  Assignments, therefore, cannot change unless the device 
  4556. adapter is reconfigured by changing jumpers.  Because of this one-to-one 
  4557. relationship, there is no separate device driver for the DMA controller.  Each 
  4558. device requiring DMA services programs the corresponding DMA channel directly 
  4559. in its device driver, as though the DMA channel were part of its own hardware. 
  4560.  
  4561. In the PS/2, virtual DMA channels may also be assigned; two of the eight 
  4562. channels, channels 0 and 4, are virtual channels which can be dynamically 
  4563. assigned to any device.  These channels can, therefore, be multiplexed to 
  4564. service more than one device.  ABIOS serializes channel accesses to avoid 
  4565. contention. 
  4566.  
  4567. Device drivers for hardware devices access the DMA channels directly, with no 
  4568. device driver required for the DMA controller itself. OS/2 Version 2.0, 
  4569. therefore, does not use a physical device driver for DMA access.  The virtual 
  4570. DMA device driver VDMA.SYS supports access to DMA ports from DOS applications 
  4571. in virtual machines. 
  4572.  
  4573. VDMA consists of port trap handlers which ignore IN/OUT commands.  The 
  4574. supported DMA services are: 
  4575.  
  4576.  Memory address and page address registers for all DMA channels 
  4577.  
  4578.  Transfer count registers for all DMA channels 
  4579.  
  4580.  Status registers 
  4581.  
  4582.  Mask registers 
  4583.  
  4584.  Mode registers 
  4585.  
  4586.  Byte pointer flip flop port 
  4587.  
  4588.  Extended function/execute ports (for PS/2 only) 
  4589.  
  4590.  Master clear ports 
  4591.  
  4592.  Command register (for PC/AT only) 
  4593.  
  4594.  Write request register (for PC/AT only). 
  4595.  
  4596. Note that VDMA does not support direct access to the DMA controller by DOS 
  4597. applications. 
  4598.  
  4599.  
  4600. ΓòÉΓòÉΓòÉ 15.4.4. Virtual Disk Device Driver ΓòÉΓòÉΓòÉ
  4601.  
  4602. The virtual disk device driver VDSK.SYS supports access to disk via the INT 13h 
  4603. CBIOS service.  Since the CBIOS accesses the hardware ports directly and may 
  4604. therefore cause problems for other processes in the system, VDSK traps the INT 
  4605. 13h interrupt and emulates the processing of this interrupt. Note that VDSK 
  4606. does not provide I/O port level access to disk controllers. 
  4607.  
  4608. The processing of an INT 13h request typically proceeds as follows: 
  4609.  
  4610.  1. The DOS application accesses the disk using INT 13h interface; the INT 13h 
  4611.     request is trapped by VDSK. 
  4612.  
  4613.  2. VDSK builds a device driver request packet and sends it to the physical 
  4614.     disk device driver.  The VDM is then blocked, waiting for the request to 
  4615.     complete. 
  4616.  
  4617.  3. The physical disk device driver processes the request packet.  If the disk 
  4618.     is currently busy, the request is queued. 
  4619.  
  4620.  4. When the request is completed, the physical disk device driver notifies 
  4621.     VDSK, which unblocks the VDM. 
  4622.  
  4623. Protected mode applications access disks via a programming interface which goes 
  4624. through the kernel's device routing mechanism and finally to the physical disk 
  4625. device driver.  The physical device driver receives an access request packet 
  4626. similar to that sent by VDSK. 
  4627.  
  4628.  
  4629. ΓòÉΓòÉΓòÉ 15.4.5. VFLPY Device Driver ΓòÉΓòÉΓòÉ
  4630.  
  4631. The virtual diskette device driver (VFLPY) intercepts virtual DOS machine 
  4632. access to the diskette drive directly or through INT 13H calls in order to 
  4633. serialize and coordinate diskette I/O between multiple virtual DOS machines. 
  4634.  
  4635.  
  4636. ΓòÉΓòÉΓòÉ 15.4.6. Virtual Keyboard Device Driver ΓòÉΓòÉΓòÉ
  4637.  
  4638. The Virtual Keyboard Device Driver VKBD.SYS provides virtualization support for 
  4639. the keyboard.  It allows keystrokes to be passed from the keyboard to virtual 
  4640. DOS machines.  It also allows for text to be pasted into the VDM as key 
  4641. strokes. 
  4642.  
  4643. Upon creation of the VDM, VKBD establishes communication with the physical 
  4644. keyboard device driver and initializes the portions of the CBIOS data area 
  4645. associated with the keyboard.  Subsequently, the physical device driver 
  4646. notifies VKBD of each scan code that is bound for the VDM. 
  4647.  
  4648. To allow monitoring of I/O activity, VKBD registers itself with the 8086 
  4649. Emulation component.  8086 Emulation then notifies VKBD when a DOS application 
  4650. in a VDM accesses a virtual keyboard port. 
  4651.  
  4652. VKBD supports two virtual I/O ports: 
  4653.  
  4654.  Port 64h - Controller Status/Command 
  4655.  
  4656.  Port 60h - Controller Input/Output Buffer. 
  4657.  
  4658. These two ports may respond to requests in a variety of ways, depending on the 
  4659. state of the controller at the time of the request. 
  4660.  
  4661. Read Output Buffer 
  4662.  
  4663. An I/O read request to port 0x60 reads the contents of the controller output 
  4664. buffer. If the "output-buffer-full" status was set before the read request, a 
  4665. timer (T1) is started.  The output-buffer-full status is then cleared.  When 
  4666. the T1 timer expires, VKBD determines if another byte is ready to be placed 
  4667. into the output buffer.  If so, the byte is placed into the output buffer and 
  4668. the "output-buffer-full" status is set. 
  4669.  
  4670. Write Output Buffer 
  4671.  
  4672. An I/O write request to port 0x60 writes the specified byte to the controller 
  4673. input buffer.  The previous contents of the input buffer are lost.  The port 
  4674. number (0x60) is saved and the byte written is processed, depending on the 
  4675. current state of the keyboard controller.  The "input-buffer-empty" status is 
  4676. never set. 
  4677.  
  4678. Status Read 
  4679.  
  4680. An I/O read request to port 0x64 simply returns the contents of the controller 
  4681. internal status register.  Reading this port has no effect on the state of the 
  4682. virtual keyboard hardware. 
  4683.  
  4684. Write Controller Command 
  4685.  
  4686. An I/O write request to port 0x64, like a write request to port 0x60, writes 
  4687. the specified byte to the controller input buffer.  Since the port number 
  4688. (0x64) is saved here, the system distinguishes between a command byte and a 
  4689. data byte.  As above, the byte written is processed, depending on the state of 
  4690. the controller, and the "input-buffer-empty" status is never set. 
  4691.  
  4692. Physical Device Driver Notification 
  4693.  
  4694. Since keystrokes are external events, it is the responsibility of the physical 
  4695. device driver to notify VKBD when keystrokes are available for processing.  In 
  4696. particular, the physical device driver calls VKBD when hardware scan codes 
  4697. arrive, and passes each scan code received to VKBD. This occurs whenever the 
  4698. keyboard's current focus is a virtual DOS machine. 
  4699.  
  4700. When called, VKBD places the scan code in a queue.  If the queue was previously 
  4701. empty, the controller "output-buffer-full" status condition is set and if 
  4702. interrupts are enabled, the Virtual Programmable Interrupt Controller is called 
  4703. to simulate the interrupt to the VDM.  If the queue was not previously empty, 
  4704. the scan code is added without any other processing.  If the queue is full, the 
  4705. speaker is sounded. 
  4706.  
  4707. INT 09h Processing 
  4708.  
  4709. In a "real" DOS environment, the IRQ1 interrupt request is translated by the 
  4710. interrupt controller, causing the INT 09h interrupt service routine to be 
  4711. invoked.  This interrupt vector normally points to a routine in the CBIOS. This 
  4712. manner of processing is not desirable in a VDM since the CBIOS only performs 
  4713. U.S. key translation; such processing would complicate the task of national 
  4714. language support.  Instead, VKBD simulates this CBIOS function, and may thus 
  4715. use whatever key translation is appropriate for the current country and code 
  4716. page. 
  4717.  
  4718. The INT 09h emulation code within VKBD performs all functions that the CBIOS 
  4719. would normally perform.  This includes: 
  4720.  
  4721.  Key and scan code enqueueing 
  4722.  
  4723.  INT 05h (Print Screen) processing 
  4724.  
  4725.  INT 15h processing for monitoring scan codes and handling the SysReq key 
  4726.  
  4727.  INT 1Bh for Ctrl+Break and Pause key processing 
  4728.  
  4729.  Key translation 
  4730.  
  4731.  Update of keyboard LEDs 
  4732.  
  4733.  Update of the CBIOS data area status. 
  4734.  
  4735. Upon termination, VKBD relinquishes access to the keyboard. 
  4736.  
  4737.  
  4738. ΓòÉΓòÉΓòÉ 15.4.7. Virtual Printer Device Driver ΓòÉΓòÉΓòÉ
  4739.  
  4740. The virtual line printer device driver VLPT.SYS supports access to three 
  4741. virtual parallel port controller devices from DOS applications running in 
  4742. virtual DOS machines. 
  4743.  
  4744. VLPT hooks INT 17h and processes requests for INT 17h services itself, rather 
  4745. than allowing these requests to be handled by CBIOS. INT 17h support includes 
  4746. support for function 02h (Read Status). 
  4747.  
  4748. VLPT does not support virtual hardware interrupts.  If a DOS application 
  4749. attempts to enable interrupts (that is, it attempts to set control port bit 4, 
  4750. "IRQ EN"), that I/O operation is ignored, and the application will not receive 
  4751. interrupts from the parallel port hardware. 
  4752.  
  4753. VLPT buffers the print data which is subsequently directed to the OS/2 spooler 
  4754. using file system services provided by the Virtual DOS Machine Manager.  The 
  4755. spooler may be configured for output on each printer device (LPTx) that will be 
  4756. accessed by DOS applications from a VDM. Figure "Virtual Printer Device Driver 
  4757. Operation" shows the various operations performed by the virtual printer device 
  4758. driver. 
  4759.  
  4760. If VLPTDD.SYS is the only virtual printer device driver installed, no INT 17 
  4761. will be issued when printing is done on numbered I/O devices (for example, 
  4762. LPT1, LPT2, etc.). However, if an application such as a TSR program must catch 
  4763. all INT 17 interrupts, the LPTDD.SYS device driver must be installed as well. 
  4764. You can find LPTDD.SYS in the subdirectory \os2\mdos. 
  4765.  
  4766. When LPTDD.SYS is available, a request from the DOS file system issuing INT 21 
  4767. is converted by LPTDD.SYS into INT 17. INT 17 is then forwarded to VLPT.SYS and 
  4768. from this point on the print request proceeds as described above in Figure 
  4769. "Virtual Printer Device Driver Operation". Note, however, that installing 
  4770. LPTDD.SYS in addition to VLPT.SYS will cause the printing from a VDM to slow 
  4771. down. 
  4772.  
  4773. Spooling 
  4774.  
  4775. In order to support spooled print output, the OS/2 spooler must be installed. 
  4776. A new IOCTL interface is defined in order to allow the spooler to identify 
  4777. itself to the physical printer device driver.  The new IOCTL functions Set 
  4778. Spooler Status and Get Spooler Status are called by the spooler and the Virtual 
  4779. DOS Machine Manager. 
  4780.  
  4781. The spooler invokes the Set Spooler Status function (Category 5, Function 4Ch) 
  4782. at spooler monitor registration time to inform the physical device driver that 
  4783. a particular port is actively configured as the output device for a particular 
  4784. spool queue.  It also invokes this interface whenever the user manipulates the 
  4785. spooler queue setup by invoking the Print Manager's Setup Printers/Change 
  4786. Printers dialog. 
  4787.  
  4788. The Virtual DOS Machine Manager invokes the Get Spooler Status function 
  4789. (Category 5, Function 6Ch) during an implicit open of a print device whenever 
  4790. VLPT processes the first print output (INT 17h) from a VDM.  This allows the 
  4791. Virtual DOS Machine Manager to determine if the spooler is active so that it 
  4792. can return the spool queue file handle to VLPT to continue printing. 
  4793.  
  4794. Print Screen 
  4795.  
  4796. VLPT also supports the Print Screen function by hooking INT 05h so that it is 
  4797. notified before the CBIOS INT 05h handler.  The CBIOS INT O5h handler invokes 
  4798. INT 17h functions, and the VLPT INT 17h emulation in turn sends this data to a 
  4799. spool file, if the spooler is active.  When the CBIOS INT 05h handler returns, 
  4800. VLPT also receives control so that it may close the spool file. 
  4801.  
  4802. File Transfer 
  4803.  
  4804. To support DOS file transfer programs which use the parallel ports (such as the 
  4805. IBM Data Migration Facility), and which typically program the parallel port 
  4806. controller directly, VLPT provides a mode known as direct I/O access. In this 
  4807. mode, the physical printer device driver grants temporary exclusive ownership 
  4808. of the parallel port hardware to the VDM in which the application is running. 
  4809. This mode allows the application to have direct access to the parallel port's 
  4810. data, status and control registers. 
  4811.  
  4812. If the port is not currently active (printing) under control of the physical 
  4813. printer device driver, the physical device driver will grant VLPT exclusive 
  4814. access to the port, and continue to service incoming file system I/O requests. 
  4815. Any incoming monitor requests from the spooler are blocked until exclusive 
  4816. access is released (no error or status monitor packets are sent to the monitor 
  4817. chain). 
  4818.  
  4819. If the physical printer device driver is actively processing a hardware I/O 
  4820. operation, when VLPT makes a request for exclusive access, the physical device 
  4821. driver will return an error code to VLPT.  VLPT will then display a pop-up 
  4822. message (via the VDHPopUp() helper service), allowing the user to select the 
  4823. most appropriate system action ("End program" or "Retry"). 
  4824.  
  4825. Note:   Due to the multitasking nature of OS/2 V2.0, data communications using 
  4826.         this type of application have an increased probability of error when 
  4827.         multiple processes are concurrently active and/or when the virtual DOS 
  4828.         machine is switched to the background. 
  4829.  
  4830. PS/2 Register Virtualization 
  4831.  
  4832. On PS/2 systems, the physical printer device driver ensures that all LPT ports 
  4833. which support extended mode (read/write 8-bit parallel I/O) will be enabled for 
  4834. extended mode at system initialization time.  On any PS/2 models which do not 
  4835. enable this mode by default, the physical printer device driver enables 
  4836. extended mode via the system's Programmable Option Select (POS) function.  This 
  4837. ensures that all PS/2 LPT ports will support manipulation of the control port 
  4838. Direction Control bit. 
  4839.  
  4840. On all PS/2 models (but not on IBM PC/AT systems), VLPT will virtualize the 
  4841. adapter enable/setup register.  All bits of this register are virtualized for 
  4842. read operations, but only bit 7 of the enable/setup register is virtualized for 
  4843. write operations.  DOS applications may modify bit 7 of this register in order 
  4844. to gain access to the system board's POS Register 2, thereby enabling or 
  4845. disabling extended mode operation of the parallel ports.  When bit 7 is set to 
  4846. 0 (the default state), the parallel port is configured as an 8-bit, parallel, 
  4847. bidirectional interface.  When bit 7 is set to 1, the parallel port 
  4848. bidirectional mode is disabled.  As described above, the physical printer 
  4849. device driver ensures that all PS/2 models have this bit set to 0 (extended 
  4850. mode enabled) during system initialization. 
  4851.  
  4852. Note that only bit 7 is virtualized and may be manipulated; attempting to 
  4853. manipulate any other bits of this register will result in termination of the 
  4854. VDM.  As the behavior is virtualized, the true state of the hardware register 
  4855. is not affected by any operations of a DOS application running in a virtual DOS 
  4856. machine. 
  4857.  
  4858. Printer Close 
  4859.  
  4860. VLPT exports the VDHPrintClose() service. This interface may be called by 
  4861. another virtual device driver such as VKBD to force any open printers in a VDM 
  4862. to close.  This technique is used to handle a forced End-of-Job 
  4863. (Ctrl+Alt+PrintScreen) character, and is required because some DOS applications 
  4864. do not explicitly close or disable the printer when their print activity is 
  4865. completed. 
  4866.  
  4867. VLPT may also close open print files whenever a VDM is terminated.  VLPT 
  4868. registers an event hook with the Virtual DOS Machine Manager, and is therefore 
  4869. notified upon termination of a VDM.  All open print files in the terminating 
  4870. VDM are closed, after any buffered data has been sent to the spooler. 
  4871.  
  4872. When operating in direct I/O access mode, VLPT can detect application 
  4873. termination in one of three ways: 
  4874.  
  4875.  PDB is changed or destroyed (default) 
  4876.  VDM is terminated 
  4877.  User hot-key (Ctrl+Alt+PrintScreen). 
  4878.  
  4879. When this termination event is detected, direct I/O access mode is cancelled 
  4880. and VLPT relinquishes the VDM's exclusive control of the parallel port 
  4881. hardware.  The physical printer device driver then reclaims ownership of the 
  4882. port and resumes normal I/O operations. 
  4883.  
  4884. Note that VLPT will not always close an open print file when the DOS 
  4885. application terminates.  Depending on the DOS application's behavior, the VDM 
  4886. may remain active when the program ends, and the spooler print file may 
  4887. therefore remain open.  If so, the user can cause the open print file(s) to 
  4888. close by using the Ctrl-Alt-PrintScreen control key sequence. Alternatively, 
  4889. the user can leave it to the system by setting the PRINT_TIMEOUT value in the 
  4890. DOS settings to the time in seconds that the operating system should wait 
  4891. before forcing the print job to the printer. Consequently there is no need to 
  4892. exit these DOS programs to have the print job released from the print spooler. 
  4893. For more information on PRINT_TIMEOUT see DOS Settings. 
  4894.  
  4895.  
  4896. ΓòÉΓòÉΓòÉ 15.4.8. Virtual Numeric Coprocessor Device Driver ΓòÉΓòÉΓòÉ
  4897.  
  4898. The virtual numeric coprocessor device driver VNPX.SYS provides virtualization 
  4899. of the 80287/80387 numeric coprocessor hardware, allowing access to numeric 
  4900. coprocessor facilities by multiple DOS applications running in virtual DOS 
  4901. machines. 
  4902.  
  4903. OS/2 Version 2.0 provides a physical device driver for the numeric coprocessor, 
  4904. within the operating system kernel.  At system initialization time, VNPX 
  4905. registers a number of hooks with the physical device driver, so that VNPX is 
  4906. informed whenever a numeric coprocessor exception or emulation trap occurs. 
  4907. Handling routines are also registered with the Virtual DOS Machine Manager, and 
  4908. are invoked upon VDM creation and termination.  Coprocessor I/O ports visible 
  4909. to V86 mode applications are hooked by VNPX. 
  4910.  
  4911. VNPX is informed by the physical device driver at initialization time, whether 
  4912. VDMs are permitted to use the coprocessor.  Upon VDM creation, VNPX sets the 
  4913. equipment summary flag for the numeric coprocessor according to the information 
  4914. received at initialization time.  In the event of the coprocessor being 
  4915. unavailable to DOS applications, the equipment summary flag is turned off.  An 
  4916. application interrogating the flag will therefore assume that no coprocessor is 
  4917. present, and take appropriate action. 
  4918.  
  4919. The first time an application in a VDM executes a coprocessor instruction 
  4920. within a particular timeslice, an exception condition (Trap 0007) occurs. The 
  4921. exception handler sets a flag within the physical device driver before allowing 
  4922. processing of the instruction to continue.  This flag is checked at task switch 
  4923. time and if it is set, the coprocessor state is saved by the physical device 
  4924. driver.  Note that the save operation takes place only if the coprocessor is 
  4925. used by an application during its timeslice; for those applications which do 
  4926. not use the coprocessor, no action is taken.  This allows optimum performance 
  4927. during task switching. 
  4928.  
  4929.  
  4930. ΓòÉΓòÉΓòÉ 15.4.9. Virtual Programmable Interrupt Controller ΓòÉΓòÉΓòÉ
  4931.  
  4932. The virtual programmable interrupt controller VPIC.SYS is a virtual device 
  4933. driver responsible for virtualization of hardware interrupts to virtual DOS 
  4934. machines.  This device driver simulates interrupts to virtual DOS machines by 
  4935. providing a virtual interface to the 8259 Programmable Interrupt Controller 
  4936. (PIC). 
  4937.  
  4938. The virtual PIC device driver supports the hardware interrupt-related services 
  4939. needed by virtual device drivers and DOS Sessions.  The services include 
  4940. setting handlers to trap EOI and IRET events, simulating interrupts to DOS 
  4941. Sessions, and handling PIC I/O accesses by DOS Sessions.  The virtual PIC 
  4942. device driver maintains a per-DOS Session virtual PIC state so that each DOS 
  4943. Session appears to have its own independent 8259 Programmable Interrupt 
  4944. Controller. 
  4945.  
  4946. This per-DOS Session virtual PIC state contains items such as the current mask, 
  4947. the current IR (interrupt request) and IS (interrupt service) registers, base 
  4948. interrupt vector and initialization mode for a particular VDM.  A per-VDM state 
  4949. machine is used to track the initialization control word (ICW) or operation 
  4950. control word (OCW) for which VPIC is waiting.  This module also invokes the 
  4951. virtual device driver's EOI handler when it receives EOI commands from a VDM. 
  4952.  
  4953. The interrupt simulation mechanism is similar to the way signals are handled 
  4954. for OS/2 applications. The virtual PIC device driver can be broken up into two 
  4955. major parts: 
  4956.  
  4957.  1. The virtualization of the PIC ports, and 
  4958.  
  4959.  2. The simulation of hardware interrupts to VDMs. 
  4960.  
  4961. Figure "Virtual Programmable Interrupt Controller" below shows this breakdown 
  4962. and the interfaces to other components, it shows the VPIC architecture and the 
  4963. role it plays in virtualizing hardware interrupts to virtual DOS machines. 
  4964.  
  4965. Not all combinations of ICWs or OCWs are supported.  Some seldom used 
  4966. initialization modes and operation commands are ignored.  These unsupported 
  4967. features are: 
  4968.  
  4969.  Slave PIC on any IRQ other than IRQ2 
  4970.  Level-triggered initialization 
  4971.  Special fully nested mode 
  4972.  Auto EOI mode 
  4973.  8080/8085 mode 
  4974.  Buffered mode 
  4975.  Special mask mode 
  4976.  Set IRQ priority command 
  4977.  Poll command 
  4978.  Rotate on specific and non-specific EOI commands. 
  4979.  
  4980. The following tables show in detail which 8259 PIC initialization and operation 
  4981. commands from a VDM are supported by the VPIC. Table "PIC Initialization 
  4982. Control Words" shows the supported and unsupported initialization control 
  4983. words. 
  4984.  
  4985. Table "PIC Operation Control Words 
  4986.  
  4987.  
  4988. ΓòÉΓòÉΓòÉ 15.4.10. Virtual Timer Device Driver ΓòÉΓòÉΓòÉ
  4989.  
  4990. The virtual timer device driver VTIMER.SYS provides virtualization of timers 
  4991. used by DOS applications running in VDMs.  Three timer ports are supported in 
  4992. order to allow reprogramming of interrupt frequency and speaker tone frequency. 
  4993. VTIMER also distributes timer ticks to VDMs and maintains a count of timer 
  4994. ticks. 
  4995.  
  4996. All accesses to the timer are simulated by VTIMER.  Therefore, unlike most 
  4997. other virtual device drivers, VTIMER has no communication with the physical 
  4998. timer.  VTIMER derives its timer tick directly from the system clock. 
  4999.  
  5000. VTIMER keeps a per-VDM cumulative timer count in the VDM's data area. When a 
  5001. periodic timer interrupt occurs, VTIMER receives control.  It adds the periodic 
  5002. interval count value to the cumulative timer count of the VDM and compares it 
  5003. with the  VDM's programmed count.  If the cumulative timer count exceeds the 
  5004. VDM's programmed count, an interrupt is simulated to the VDM and the programmed 
  5005. count is subtracted from the cumulative timer count. 
  5006.  
  5007. Timer 0 
  5008.  
  5009. This timer is normally used to provide periodic interrupts to DOS applications. 
  5010. A periodic system timer with an interval close to 18.2 milliseconds is set up 
  5011. so that VTIMER can accumulate virtual ticks and simulate tick interrupts if 
  5012. necessary. 
  5013.  
  5014. If a VDM attempts to program an interrupt period less than 18.2 milliseconds, 
  5015. the periodic timer interval will be changed to four times the normal frequency 
  5016. of 18.2 Hz, regardless of the VDM's programmed value.  A HighRate reference 
  5017. count is also kept to record the number of VDMs using a higher interrupt rate. 
  5018. As long as there is at least one VDM using a higher interrupt rate, the 
  5019. periodic rate is maintained at approximately four times 18.2 Hz.  Otherwise, 
  5020. the timer frequency is reset to 18.2 Hz. 
  5021.  
  5022. Accesses to timer count registers from within a VDM are trapped by VTIMER. 
  5023. Read accesses to the count registers should be preceded by a counter latch 
  5024. command written to the control word register, in which case a random value 
  5025. derived from the system time is latched and stored in the virtual latch 
  5026. registers.  Its purpose is to provide the applications with a sense of elapsed 
  5027. time, although the count value itself is meaningless. Read access to the count 
  5028. register is simulated by reading the virtual latch value.  Write accesses to 
  5029. the count registers are stored in the virtual count registers. 
  5030.  
  5031. Timer 1 
  5032.  
  5033. Timer 1 is used in the PC AT [Although the IBM PC AT is based on the Intel 
  5034. 80286 processor and therefore is not supported by OS/2 Version 2.0, many PC AT 
  5035. machines exist which have been fitted with processor upgrades from various 
  5036. manufacturers, which may enable them to run OS/2 Version 2.0.  Information on 
  5037. the PC AT architecture is therefore included herein for completeness. ] as the 
  5038. memory refresh request timer.  Since the correct operation of this timer is 
  5039. vital to the system, no known software reprograms it for uses other than 
  5040. reading it as the random number generator speed.  Therefore, VTIMER does not 
  5041. support any access except counter read to this timer by DOS applications.  Any 
  5042. accesses other than counter reads are trapped and ignored. 
  5043.  
  5044. Timer 2 
  5045.  
  5046. Timer 2 is the speaker tone generator.  It is accessed by DOS applications 
  5047. directly, via programming interfaces or DevHlp services, or by the VDHBeep() 
  5048. function. Serialization of the speaker usage can be achieved by using a 
  5049. semaphore in the kernel. 
  5050.  
  5051. When a DOS application accesses the speaker, it typically programs timer 2 for 
  5052. the appropriate frequency and then enables the speaker by programming the 
  5053. speaker enable bits in system control port B.  These programming operations are 
  5054. trapped by VTIMER and the frequency value is stored for the VDM.  When Control 
  5055. Port B is programmed to enable the speaker, the kernel beep service is called 
  5056. to generate the beep. This call may be blocked due to the fact that another 
  5057. process is beeping and thus owns the speaker semaphore.  After the semaphore is 
  5058. obtained, the stored frequency value is programmed into timer 2 and the speaker 
  5059. is enabled. The semaphore is released when the DOS application disables the 
  5060. speaker by programming the System Control Port B. 
  5061.  
  5062. There is one exception to the speaker serialization, and this occurs during 
  5063. interrupt time.  For example, when a process is generating a speaker tone, the 
  5064. keyboard buffer may be full and the keyboard interrupt handler needs to 
  5065. generate a warning beep immediately.  Therefore, the kernel also provides an 
  5066. interrupt time beep service which can pre-empt any ongoing beeps and use the 
  5067. speaker to generate its own beep regardless of which process currently owns the 
  5068. speaker semaphore. 
  5069.  
  5070.  
  5071. ΓòÉΓòÉΓòÉ 15.4.11. Virtual COM Device Driver ΓòÉΓòÉΓòÉ
  5072.  
  5073. The virtual COM device driver VCOM.SYS provides virtual support for the serial 
  5074. communication I/O ports and for the serial channel-related CBIOS entry points. 
  5075. It provides support in each VDM for up to two communication channels on the IBM 
  5076. PC AT and compatible systems, and up to four on the IBM PS/2 Model 80 and 
  5077. compatible PS/2 systems. 
  5078.  
  5079. VCOM only supports access to communication channels which are physically 
  5080. present on a given system.  It does not include support for accessing 
  5081. communication devices which may be redirected by network software.  For each 
  5082. supported port, VCOM searches for the port's base address in the CBIOS data 
  5083. area.  If the address is zero, indicating that the device is not present or is 
  5084. owned by a physical device driver other than the COM.SYS device driver, VCOM 
  5085. does not attempt to support that serial device. 
  5086.  
  5087. If the port's base address is found, VCOM verifies that the physical device 
  5088. driver has installed itself for that serial device.  If the physical device 
  5089. driver indicates it is not installed for that port, VCOM does not attempt to 
  5090. support that serial device. 
  5091.  
  5092. Many DOS applications that support asynchronous communications include hardware 
  5093. interrupt handler routines.  These routines typically perform I/O directly to 
  5094. the COM port hardware. To support these DOS applications and to allow them to 
  5095. run in both background and foreground, VCOM simulates hardware interrupts in 
  5096. the task-time context of the V86 mode process. VDMs are scheduled and 
  5097. dispatched using the same preemptive task dispatching method that drives OS/2 
  5098. processes.  Hardware interrupts on the other hand, occur asynchronously to this 
  5099. scheduling process.  By simulating hardware interrupts and presenting a virtual 
  5100. hardware state, the interrupt handling logic of the DOS application does not 
  5101. execute on the physical interrupt thread.  This means that switching to V86 
  5102. mode is not done at interrupt time, but is deferred until the scheduler 
  5103. dispatches the VDM task. 
  5104.  
  5105. The advantage of simulated interrupts is that mode switching and hardware 
  5106. virtualization need not be done at interrupt time.  In addition, the DOS 
  5107. application does not gain control at interrupt time, which helps to maintain 
  5108. system integrity.  A potential disadvantage of this approach is that DOS 
  5109. applications with time-critical routines may not operate correctly under some 
  5110. system load configurations. 
  5111.  
  5112. Port/Channel Contention 
  5113.  
  5114. After VDM creation, the CBIOS data area provides a logical link between the 
  5115. virtual communication channels in the VDM and the physical serial channel 
  5116. hardware.  Since VCOM does not support a COM port if its address is not in the 
  5117. CBIOS area, it can handle its own errors and/or terminate in its usual fashion 
  5118. if the DOS application does not find the device address. 
  5119.  
  5120. If the CBIOS area indicates that the device is present, however, VCOM 
  5121. determines if the device is already in use in another VDM when the DOS 
  5122. application makes its first access to that device.  If so, VCOM does not 
  5123. attempt to send the OPEN command to the physical device driver.  Instead, VCOM 
  5124. will issue a pop-up message that informs the user of the resource contention 
  5125. and allows for a user-selected action.  As a result of the user action, the 
  5126. conflict is resolved or the VDM may be terminated. 
  5127.  
  5128. If the port is not already in use, VCOM calls the physical device driver with 
  5129. the OPEN command.  This command will succeed provided the port is not currently 
  5130. in use by a protected mode process. 
  5131.  
  5132. Once the device is opened, VCOM communicates directly with the physical device 
  5133. driver to perform all virtual hardware operations.  These include sending and 
  5134. receiving data, detection and simulation of hardware interrupts, and setting or 
  5135. querying the status and control registers. 
  5136.  
  5137. CBIOS Access 
  5138.  
  5139. VCOM also supports access to CBIOS COM port services through software interrupt 
  5140. 14h.  Rather than allowing the CBIOS to perform the functions by accessing the 
  5141. virtual I/O ports directly, VCOM emulates CBIOS functions. The CBIOS access 
  5142. emulation supports six functions: 
  5143.  
  5144.  Initialize 
  5145.  
  5146.   The initialize function establishes the communication speed and framing 
  5147.   options for the channel, and returns the modem and line status.  To specify 
  5148.   bit rates of greater than 9600 bits per second, the extended initialize 
  5149.   function must be used. 
  5150.  
  5151.  Extended Initialize 
  5152.  
  5153.   The extended initialize function, like the initialize function, establishes 
  5154.   the communication speed and framing options for the channel and returns the 
  5155.   modem and line status.  This function is used if a bit rate of 19,200 bits 
  5156.   per second (or greater) is desired,  or if space or mark parity selection is 
  5157.   desired. 
  5158.  
  5159.  Send Character 
  5160.  
  5161.   The send character function sends a character to the communication channel. 
  5162.  
  5163.  Receive Character 
  5164.  
  5165.   The receive character function waits for a character from the communication 
  5166.   channel and returns the character. 
  5167.  
  5168.  Read Status 
  5169.  
  5170.   The read status function returns the modem and line status. 
  5171.  
  5172.  Extended Port Control 
  5173.  
  5174.   The extended port control function sets or reads the modem control register. 
  5175.  
  5176. DOS applications running in VDMs may access these functions using the standard 
  5177. INT 14h service, in a manner identical to that used in a native DOS 
  5178. environment. 
  5179.  
  5180. Virtual Interrupt Indication 
  5181.  
  5182. The DOS application must properly enable interrupts and the specific interrupt 
  5183. type before the interrupt will be simulated to the VDM.  The following INS8250 
  5184. interrupt types are virtualized by VCOM: 
  5185.  
  5186.  Line Status Interrupt 
  5187.  
  5188.  Receive Data Available Interrupt 
  5189.  
  5190.  Transmitter Holding Register Empty Interrupt 
  5191.  
  5192.  Modem Status Interrupt. 
  5193.  
  5194. When the physical device driver notifies VCOM of an interrupt, VCOM passes a 
  5195. virtual interrupt to the Virtual Programmable Interrupt Controller, which in 
  5196. turn simulates the interrupt to the VDM. 
  5197.  
  5198. To maintain high performance on the physical serial channel, the COM physical 
  5199. device driver typically does not notify the VCOM on every interrupt.  Rather, 
  5200. VCOM receives notification of certain events, and determines whether to begin 
  5201. or continue simulating interrupts to the VDM. 
  5202.  
  5203. Coexistence with Other Serial Device Drivers 
  5204.  
  5205. Since there is always the potential for other device drivers to own a serial 
  5206. port, VCOM does not assume ownership of any devices for which the physical COM 
  5207. device driver has not been installed.  For example, a serial mouse device 
  5208. driver may be installed and may own the COM1 serial port.  The COM physical 
  5209. device driver will not install for this port, and VCOM will therefore support 
  5210. only the higher numbered serial ports (if installed). 
  5211.  
  5212. If a physical device driver installs itself and zeros the COM port base 
  5213. addresses in the CBIOS data area, VCOM does not attempt to initialize for that 
  5214. COM port and will not assume any responsibility to virtualize the serial device 
  5215. hardware for that port.  This may result in problems for certain DOS 
  5216. applications which rely on the CBIOS data area in order to access multiple 
  5217. serial ports. 
  5218.  
  5219.  
  5220. ΓòÉΓòÉΓòÉ 15.4.12. VDPMI Device Driver ΓòÉΓòÉΓòÉ
  5221.  
  5222. The virtual DOS Protected Mode Interface(VDPMI) device driver provides Version 
  5223. 0.9 DPMI support for virtual DOS machines. DPMI applications run in protected 
  5224. mode, not V86 mode. VDPMI allows the user to specify how much protected mode 
  5225. memory should be made available to a DOS session using the DPMI_MEMORY_LIMIT 
  5226. setting in the settings notebook. 
  5227.  
  5228.  
  5229. ΓòÉΓòÉΓòÉ 15.4.13. VDPX Device Driver ΓòÉΓòÉΓòÉ
  5230.  
  5231. The virtual DOS Protected Mode Extender(VDPX) device driver provides address 
  5232. translation from protected mode to V86 mode for DPMI applications running in 
  5233. virtual DOS machines. This translation is necessary because DPMI applications 
  5234. run in protected mode but issue interrupt requests in V86 mode to perform 
  5235. systems services. 
  5236.  
  5237. The VDPX device driver registers the DOS Setting called DPMI_DOS_API. The 
  5238. available settings are: 
  5239.  
  5240. Enabled      VDPX always translates the interrupts it supports from protected 
  5241.              mode to V86 mode 
  5242.  
  5243. Auto         The application must issue an INT 2FH in protected mode to begin 
  5244.              the translation 
  5245.  
  5246. Disabled     VDPX does not perform any address translation. 
  5247.  
  5248.  
  5249. ΓòÉΓòÉΓòÉ 15.4.14. VXMS Device Driver ΓòÉΓòÉΓòÉ
  5250.  
  5251. The Extended Memory Specification (XMS) Version 2.0 provides a standard 
  5252. interface for the use of three regions of extended memory on 80286 and 80386 
  5253. machines: 
  5254.  
  5255.  High Memory Area (HMA), accessible in real mode if the A20 address line is 
  5256.   enabled 
  5257.  Extended Memory Blocks(EMBs), up to 64MB that is used for data storage 
  5258.  Upper Memory Blocks(UMBs), located between 640KB and 1MB in conventional 
  5259.   memory. 
  5260.  
  5261. The Virtual Extended Memory Specification(VXMS) device driver 
  5262.  
  5263.  Implements all the functions of XMS Version 2.0 
  5264.  Provides each virtual DOS machine with its own separate XMS emulation 
  5265.  Provides configurable limits on the amount of extended memory for each 
  5266.   virtual DOS machine separately. 
  5267.  
  5268. The VXMS device driver is installed via CONFIG.SYS, with the following syntax 
  5269. and options: 
  5270.  
  5271. Syntax 
  5272.  
  5273. DEVICE=\OS2\MDOS\VXMS.SYS [options]
  5274.  
  5275. Options 
  5276.  
  5277. /XMMLIMIT=g,i Set the global maximum memory usage of VXMS to gKB, and the per 
  5278.           virtual DOS machine limit to iKB. The default is 16384,2048. 
  5279.  
  5280. /HMAMIN=d Minimum request size in KB for an HMA request to succeed. The default 
  5281.           is 0, the maximum is 63. 
  5282.  
  5283. NUMHANDLES=n Number of handles available to each virtual DOS machine. Handles 
  5284.           are used to access EMBs. The maximum is 128 and the default is 32. 
  5285.  
  5286. /UMB      Create UMBs. The default is not to create any. 
  5287.  
  5288. /NOUMB    Do not create UMBs. This is the default setting. 
  5289.  
  5290.  
  5291. ΓòÉΓòÉΓòÉ 15.4.15. VEMM Device Driver ΓòÉΓòÉΓòÉ
  5292.  
  5293. The Lotus-Intel-Microsoft (LIM) Expanded Memory Specification (EMS) Version 4.0 
  5294. provides a standard interface for the use of expanded memory on 8086 and 8088 
  5295. machines. The specification offers up to 32MB of expanded memory divided into 
  5296. up to 255 objects that can be mapped into conventional memory. 
  5297.  
  5298. The Virtual Expanded Memory Specification (VEMM) virtual device driver: 
  5299.  
  5300.  Implements all the INT 67H functions in LIM 4.0 EMS, except those for DMA 
  5301.   registers 
  5302.  Provides each virtual DOS machine with its own separate EMS emulation 
  5303.  Supports remapping of conventional memory for use by DOS programs 
  5304.  Provides a configurable limit to EMS memory for each virtual DOS machine 
  5305.  Supports multiple physical to single logical memory mappings so that 
  5306.   different 8086 addresses can be mapped to the same expanded memory object 
  5307.   address. 
  5308.  
  5309. The VEMM device driver is installed via CONFIG.SYS, with the following syntax 
  5310. and options: 
  5311.  
  5312. Syntax 
  5313.  
  5314. DEVICE=\OS2\MDOS\VEMM.SYS [options]
  5315.  
  5316. Options 
  5317.  
  5318. /S=n      EMS memory limit per virtual DOS machine, with the default being 
  5319.           2048. This can also be set with the EMS_MEMORY_LIMIT setting in the 
  5320.           settings notebook for the virtual DOS machine. 
  5321.  
  5322. /L=n      Size of the remappable conventional memory. This can also be set with 
  5323.           the EMS_LOW_OS_MAP_REGION setting in the settings notebook for the 
  5324.           virtual DOS machine. 
  5325.  
  5326. /H=n      Size of the extra mappable memory, with the default being 32. This 
  5327.           can also be set with the EMS_HIGH_OS_MAP_REGION setting in the 
  5328.           settings notebook for the virtual DOS machine. 
  5329.  
  5330. /F=xxxx   Frame location for remapping expanded memory into conventional 
  5331.           memory. The default is AUTO. This can also be set with the 
  5332.           EMS_FRAME_LOCATION setting in the settings notebook for the virtual 
  5333.           DOS machine. The frame location may need to be moved if there is a 
  5334.           conflict with the mapping address of a physical device driver that 
  5335.           does not have a corresponding virtual device driver. Refer to DOS 
  5336.           Settings on how to use the MEMORY_INCLUDE_REGIONS and 
  5337.           MEMORY_EXCLUDE_REGIONS settings when memory conflicts occur. 
  5338.  
  5339.  
  5340. ΓòÉΓòÉΓòÉ 15.4.16. VWIN Device Driver ΓòÉΓòÉΓòÉ
  5341.  
  5342. "Seamless" WIN-OS/2 support is the ability to run Windows applications in a 
  5343. window right on top of the Workplace Shell desktop. This requires the Windows 
  5344. video device driver and the PM video device driver communicate and coordinate 
  5345. their access of the video hardware.  Each device driver effectively owns its 
  5346. piece of the screen.  Allowing the Windows display device driver to access the 
  5347. video hardware directly avoids the more cumbersome process of a thorough task 
  5348. switch. However this hardware access poses integrity problems in the areas of 
  5349. simultaneous access of hardware, rectangle invalidation handling, window 
  5350. management, and the exchange of window state information between PM and 
  5351. seamless VDMs supported by separate video device drivers. 
  5352.  
  5353. To address these problems, a high performance, interprocess communication, 
  5354. virtual device driver (VWIN.SYS) was created.  It serializes the simultaneous 
  5355. accesses to the hardware, oversees the exchange of window state information 
  5356. between PM and seamless VDMs, and establishes the addressability of PM 
  5357. resources (either directly or indirectly) by the Windows display device driver. 
  5358.  
  5359.  
  5360. ΓòÉΓòÉΓòÉ 15.4.17. Virtual Mouse Driver ΓòÉΓòÉΓòÉ
  5361.  
  5362. Given the diversity of mouse hardware, and the complexity of dealing with all 
  5363. possible combinations of mouse hardware and video equipment, few if any 
  5364. applications talk directly to mouse hardware.  Most applications which support 
  5365. a mouse do so through the INT 33h interface.  Virtualization of the INT 33h 
  5366. interface is provided by the virtual mouse device driver VMOUSE.SYS. 
  5367.  
  5368. The INT 33h interface performs the following: 
  5369.  
  5370.  Position and button tracking 
  5371.  
  5372.  Position and button event notification 
  5373.  
  5374.  Selectable pixel and mickey mappings 
  5375.  
  5376.  Video mode tracking 
  5377.  
  5378.  Video pointer management (location and appearance) 
  5379.  
  5380.  Light pen emulation. 
  5381.  
  5382. The interface between the physical mouse driver and VMOUSE is straightforward. 
  5383. The physical mouse driver is aware at all times of which session owns the 
  5384. mouse; thus, when a foreground VDM owns the mouse, it notifies VMOUSE of mouse 
  5385. events.  The events themselves remain buffered by the physical device driver 
  5386. until VMOUSE requests them.  Normally, VMOUSE asks for each event immediately, 
  5387. and updates the INT 33h data structures for the foreground VDM, unless the 
  5388. application running in the VDM has registered a mouse event subroutine. 
  5389.  
  5390. If a mouse event subroutine has been registered by the application, VMOUSE may 
  5391. have to notify the routine of a mouse event.  This depends on the events for 
  5392. which the subroutine has requested notification.  When a registered subroutine 
  5393. must be called, VMOUSE requests a fake interrupt to be simulated into the VDM. 
  5394. A fake interrupt service routine (loaded into each VDM upon creation) 
  5395. immediately emulates the interrupt and then proceeds to notify the VDM's 
  5396. registered subroutine.  In order to pick an IRQ that is guaranteed to not 
  5397. conflict with any other virtual device driver, VMOUSE queries the physical 
  5398. mouse driver at initialization time for the physical IRQ used by the mouse. 
  5399. This ensures that no conflict occurs. 
  5400.  
  5401. Position and Button Data Tracking 
  5402.  
  5403. Position and button events are interrupt time events that are communicated to 
  5404. VMOUSE by the physical device driver via a "data ready" entry point.  If the 
  5405. VDM is not already processing a previous event, VMOUSE calls the physical 
  5406. device driver to get the new event; otherwise, VMOUSE waits until previous 
  5407. event processing is complete.  This avoids the need for buffering within 
  5408. VMOUSE. 
  5409.  
  5410. Normally, the VDM will not be processing any events, so position and button 
  5411. information can be immediately retrieved and stored for later query by a VDM 
  5412. application, via INT 33h. 
  5413.  
  5414. Position and Button Event Notification 
  5415.  
  5416. As events are requested and supplied by the physical mouse driver, VMOUSE peeks 
  5417. ahead to the next event (if any) and, if it is a movement-only event, extracts 
  5418. it and overlays the current event.  This is continued until there are no more 
  5419. events, or the next event is not a movement-only event.  This reduces the 
  5420. amount of interrupt-simulation overhead during periods of rapid mouse movement. 
  5421.  
  5422. Selectable Pixel-to-Coordinate and Mickey-to-Pixel Mappings 
  5423.  
  5424. Since pixel-to-virtual-coordinate mappings are often used by DOS applications 
  5425. but are not supported for protected mode applications;  VMOUSE manages such 
  5426. mappings.  Since mickey-to-pixel mappings are supported for protected mode, 
  5427. VMOUSE relies on the physical mouse driver to perform these mappings.  Thus 
  5428. physical mouse driver interfaces are provided to set the mickey-to-pixel 
  5429. mapping and the dimensions of the screen in pixels. 
  5430.  
  5431.  
  5432. ΓòÉΓòÉΓòÉ 15.4.18. VCDROM Device Driver ΓòÉΓòÉΓòÉ
  5433.  
  5434. The VCDROM virtual device driver enables audio support for CD-ROM applications 
  5435. running in virtual DOS machines. In native DOS, audio and other IOCTL support 
  5436. is provided by the pass-through function of the CD-ROM file system driver, 
  5437. MSCDEX. VCDROM provides two features necessary to support DOS CD-ROM 
  5438. applications: 
  5439.  
  5440.  It emulates the presence of the MSCDEX 
  5441.  It translates the DOS style IOCTLs into requests that the physical CD-ROM 
  5442.   device driver can understand. 
  5443.  
  5444. VCDROM provides only audio IOCTL support and not a full emulation of MSCDEX, as 
  5445. most DOS CD-ROM applications use the standard DOS interface for file system 
  5446. services and the MSCDEX interface for audio services only. Any application that 
  5447. calls MSCDEX for file system services will not run in a virtual DOS machine. 
  5448.  
  5449.  
  5450. ΓòÉΓòÉΓòÉ 15.4.19. Virtual Video Device Driver ΓòÉΓòÉΓòÉ
  5451.  
  5452. VDM video activity consists of both port I/O and memory operations. Virtual 
  5453. video device drivers are provided to support concurrent operations by multiple 
  5454. VDMs.  A number of virtual video device drivers are provided by OS/2 Version 
  5455. 2.0, and are installed depending upon the physical display adapter types 
  5456. present in the system: 
  5457.  
  5458.  VCGA.SYS provides support for CGA devices 
  5459.  
  5460.  VEGA.SYS provides support for EGA devices 
  5461.  
  5462.  VVGA.SYS provides support for VGA devices 
  5463.  
  5464.  VSVGA.SYS provides support for SVGA devices 
  5465.  
  5466.  VEGB.SYS provides support for VGA devices when configured to operate in EGA 
  5467.   modes only 
  5468.  
  5469.  V8514.SYS provides support for the display adapter 8514/A 
  5470.  
  5471.  VXGA.SYS provides support for the XGA display adapter. 
  5472.  
  5473. In the following discussion, the term VVIDEO will be used generically to refer 
  5474. to all virtual video device drivers. 
  5475.  
  5476. By trapping all I/O operations and mapping a virtual video memory buffer to the 
  5477. region where a VDM expects physical video memory, VVIDEO insulates the physical 
  5478. hardware from background VDM  activity.  Only a foreground VDM's video 
  5479. operations are allowed to write directly to the physical hardware. 
  5480.  
  5481. The major IBM adapter types (MONO, CGA, EGA, VGA, XGA and 8514) are fully 
  5482. supported by VVIDEO, in that it supports all standard modes of operation for 
  5483. multiple VDMs (concurrently, if all VDMs are running in text modes). 
  5484.  
  5485. The following is a list of the video configurations supported and their default 
  5486. mode of operation: 
  5487.  
  5488. Table "List of Supported Video Configurations" 
  5489.  
  5490. As in a native DOS environment, the default setting of the equipment flags 
  5491. determines which display adapter is the primary display.  VVIDEO examines this 
  5492. to determine which will be the primary display. The video signal for secondary 
  5493. displays is initially disabled, until such time as a MODE command or user 
  5494. application explicitly enables it. 
  5495.  
  5496. VDM Screen-Switching 
  5497.  
  5498. The OS/2 Version 2.0 session manager informs VVIDEO whenever a VDM's display 
  5499. state changes, ensuring that no more than one foreground VDM exists at any 
  5500. point in time, and that no VDMs are regarded as foreground processes while any 
  5501. other protected mode process, including the operating system shell, is in 
  5502. foreground.  This mutually exclusive activity relationship between VVIDEO and 
  5503. OS/2 display drivers ensures screen integrity. 
  5504.  
  5505. VDMs in background are switchable at any time since their state is maintained 
  5506. in memory by VVIDEO, rather than in the device itself.  32KB of virtual video 
  5507. buffer memory is allocated by VVIDEO for each VDM upon creation.  This is the 
  5508. maximum buffer size addressable in any text mode. When the VDM is switched to 
  5509. foreground, the video buffer is reallocated to the maximum size supported by 
  5510. the adapter, with a limit of 256KB. 
  5511.  
  5512. The act of switching a VDM from foreground to background or vice versa requires 
  5513. that the calling routine yield control, and hence there may be a time delay 
  5514. during the switch.  In order to preserve the integrity of the video buffer, the 
  5515. VDM is suspended for the duration of the screen switch, to avoid any portion of 
  5516. the video state that was already copied to or from the hardware being changed 
  5517. before the switch is complete. 
  5518.  
  5519. Foreground VDM Support 
  5520.  
  5521. There are literally no limits to what a VDM can do with video hardware when 
  5522. running in foreground, since it has complete access to all ports and device 
  5523. memory through VVIDEO.  I/O trapping is still operative, but only to "shadow" 
  5524. changes and ensure the ability to switch screens. 
  5525.  
  5526. Background VDM Support 
  5527.  
  5528. VDMs running in the background must always use virtual video memory, which is 
  5529. actually normal system memory that has been mapped into the VDM's video address 
  5530. space.  In cases where the selected video mode (typically a graphics mode) 
  5531. requires multiple planes of video memory, normal system memory is inadequate to 
  5532. effectively virtualize video memory. 
  5533.  
  5534. Whenever a VDM running the in background places the video hardware in a 
  5535. multi-plane graphics mode, virtual video memory is invalidated and if touched, 
  5536. results in the VDM being "frozen". If the VDM returns to a single-plane video 
  5537. mode (implying that it never accessed video memory), then its virtual video 
  5538. memory is validated once more.  This approach allows VDMs to switch between 
  5539. different text modes entirely in background, without the risk of being frozen. 
  5540.  
  5541. To support graphics operation in the background, VVIDEO must trap all video 
  5542. memory references and remap them to a set of simulated planes, or use some form 
  5543. of hardware-assisted virtualization that Presentation Manager and the other 
  5544. OS/2 processes know nothing about. 
  5545.  
  5546. Suspended Background VDM:  There are three cases in which DOS graphics 
  5547. applications may be suspended (receive no processor time) when running in the 
  5548. background: 
  5549.  
  5550.  1. A DOS multiplane graphics application that uses advanced graphics, such as 
  5551.     640x480x16 or 640x350x16, will be suspended, regardless of the graphics 
  5552.     adapter installed, if any other DOS application is running in the 
  5553.     foreground in a full-screen session. 
  5554.  
  5555.  2. A DOS multiplane graphics application that uses advanced graphics, such as 
  5556.     640x480x16 or 640x350x16, will be suspended when a Presentation Manager 
  5557.     session is running in the foreground in XGA mode. Currently, this situation 
  5558.     occurs even if you have an Extended Graphics Array (XGA) and a Video 
  5559.     Graphics Array (VGA) adapter connected to your system. 
  5560.  
  5561.  3. A DOS multiplane graphics application that uses 1024x768x16 graphics mode 
  5562.     will be suspended when a Presentation Manager session is running in the 
  5563.     foreground in 8514/A mode. 
  5564.  
  5565. Note that suspending DOS applications running in the background generally poses 
  5566. no problems unless the applications are timing-dependent, such as 
  5567. communications or process-control applications. In these cases, suspending them 
  5568. may cause them to fail. Avoid this situation by running these applications in 
  5569. the foreground in full-screen sessions only. If they are graphics applications, 
  5570. run them only in a single-plane mode, such as 640x200x2, 320x200x256, or 
  5571. 640x480x2, in full-screen sessions. 
  5572.  
  5573. Note also that for WIN-OS/2 sessions, set the VIDEO_SWITCH_NOTIFICATION DOS 
  5574. setting to ON to avoid having Windows programs suspended when running in the 
  5575. background. 
  5576.  
  5577. Graphical Applications Programs Support:  OS/2 Version 2.0 supports a broad 
  5578. variety of display-adapter hardware as you can see from Table "Graphical 
  5579. Applications Programs Support under OS/2 Version 2.0". This allows OS/2 
  5580. programs, DOS programs, and Windows programs to run in both windowed and 
  5581. full-screen sessions. OS/2, DOS, and Windows programs can run successfully in 
  5582. both the foreground and the background.  Normally, the OS/2 user need not be 
  5583. concerned with the graphics modes that are used within a program, or whether a 
  5584. program will run successfully in a background session. 
  5585.  
  5586. Some types of display adapters do, however, place limits on the ability of the 
  5587. OS/2 operating system to run certain classes of DOS and Windows graphics 
  5588. programs in the background. The limits exist because of the difficulty of 
  5589. providing virtual access to the display-adapter hardware without disturbing 
  5590. either the foreground session or other background sessions. 
  5591.  
  5592. Under certain conditions, DOS applications that use graphical display modes 
  5593. will become suspended in background sessions when they attempt to write to the 
  5594. display. 
  5595.  
  5596. Table "Graphical Applications Programs Support under OS/2 Version 2.0" gives 
  5597. you an overview of what happens with graphical applications programs in 
  5598. combination with different display adapters. 
  5599.  
  5600. To determine under what conditions your applications will run in a background 
  5601. session in Table "Graphical Applications Programs Support under OS/2 Version 
  5602. 2.0" as described now: 
  5603.  
  5604.  1. Find your graphical display hardware in the "Type of Video" column. 
  5605.  
  5606.  2. Find your System Desktop Mode. 
  5607.  
  5608.  3. Read across the table to your application column. 
  5609.  
  5610. For example, assume you have a DOS application using VGA mode on a system with 
  5611. VGA video. The application is in full-screen. To determine if the application 
  5612. will be suspended: 
  5613.  
  5614.  1. Find your type of video (VGA) in the "Type of Video" column. 
  5615.  
  5616.  2. Find your System Desktop Mode (VGA). 
  5617.  
  5618.  3. Read across the table to your application column (DOS Application, Matches 
  5619.     Desktop Mode, Full-Screen). 
  5620.  
  5621. The PF indicates that the DOS application runs when PM has control of the 
  5622. screen or when the application is in a foreground session. 
  5623.  
  5624. Device-Independent Pointer Services 
  5625.  
  5626. VVIDEO provides services which allow the virtual mouse driver to define a 
  5627. pointer image and specify its position.  Since the position must always be 
  5628. given relative to the physical dimensions of the VDM's screen, and since 
  5629. coordinates may change whenever the video mode is reset, the virtual mouse 
  5630. driver provides an entry point which is notified of such changes by VVIDEO. 
  5631. These interfaces are device-independent because dimensions are always given in 
  5632. terms of pixels or character cells, and not in predefined video mode 
  5633. identifiers.  By separating the pointer-drawing code from the virtual mouse 
  5634. driver, mouse support becomes automatically available on any video adapter. 
  5635.  
  5636. Font Support 
  5637.  
  5638. At VDM creation time only a single font exists; this is either a default font 
  5639. contained in video ROM, or one specified by OS/2 if code page support is 
  5640. active.  In the latter case, VVIDEO automatically loads the OS/2 code page font 
  5641. whenever the VDM restores the default ROM font by resetting the video mode. 
  5642.  
  5643. Note that since the process of loading a font is essentially the same as 
  5644. entering a graphics mode, background VDMs will "freeze" if they attempt this. 
  5645.  
  5646. Clipboard Support 
  5647.  
  5648. To transfer VDM screen contents to the clipboard, VVIDEO provides two services: 
  5649. one to return the VDM's video configuration, and a second to copy the video 
  5650. contents to a shell-supplied buffer address.  The shell then handles the 
  5651. transfer from this buffer to the clipboard. 
  5652.  
  5653.  
  5654. ΓòÉΓòÉΓòÉ 15.5. Virtual Device Helper Services ΓòÉΓòÉΓòÉ
  5655.  
  5656. In order to allocate, free and reallocate memory, virtual device drivers use 
  5657. the virtual device helper (VDH) memory management services. These services help 
  5658. the virtual device driver maintain a linear heap for each VDM.  This heap is 
  5659. maintained as a linked list; each entry in this linked list refers to a linear 
  5660. region with attributes such as: 
  5661.  
  5662.  Reserved 
  5663.  Allocated 
  5664.  Mapped 
  5665.  Page granular 
  5666.  Byte granular. 
  5667.  
  5668. Memory allocation is always done in chunks of 4KB (page granular), but byte 
  5669. granular services are provided for handling instance data reservations and for 
  5670. memory allocation in the DOS environment. 
  5671.  
  5672.  
  5673. ΓòÉΓòÉΓòÉ 15.5.1. Memory Management ΓòÉΓòÉΓòÉ
  5674.  
  5675. VDH services provide the following support for memory management within virtual 
  5676. device drivers: 
  5677.  
  5678.  Allocation/reallocation/freeing services for: 
  5679.  
  5680.    - Global and per-VDM objects 
  5681.    - Page and byte granular objects 
  5682.    - Options for fixed, swappable allocations. 
  5683.  
  5684.  Allocation of memory in DOS environment 
  5685.  
  5686.  Reserve specified linear space 
  5687.  
  5688.  V86-mode stack manipulation 
  5689.  
  5690.  Mapping services: 
  5691.  
  5692.    - Map to physical address 
  5693.    - Map to linear address 
  5694.    - Map to invalid address 
  5695.    - Map to black holes (don't care) pages 
  5696.  
  5697.  Copy/exchange services 
  5698.  
  5699.  Block management services (pools of equal-size memory blocks) 
  5700.  
  5701.  Query services: 
  5702.  
  5703.    - Query the biggest linear space in a specified range 
  5704.    - Query dirty bits for set of pages 
  5705.    - Query amount of free virtual memory. 
  5706.  
  5707.  
  5708. ΓòÉΓòÉΓòÉ 15.5.2. Semaphore Services ΓòÉΓòÉΓòÉ
  5709.  
  5710. These services are used to synchronize a virtual device driver with another 
  5711. OS/2 process.  If a virtual device driver blocks a VDM process, that VDM will 
  5712. not receive any simulated hardware interrupts until it becomes unblocked.  VDH 
  5713. semaphore services are used to handle the following: 
  5714.  
  5715.  Mutual exclusion and event semaphores 
  5716.  OS/2 process to physical device driver communication 
  5717.  Virtual device driver/physical device driver communication 
  5718.  VDM event list management. 
  5719.  
  5720.  
  5721. ΓòÉΓòÉΓòÉ 15.5.3. Freeze/Thaw Services ΓòÉΓòÉΓòÉ
  5722.  
  5723. The virtual video device driver uses these services to freeze and unfreeze the 
  5724. operation of a VDM.  This is typically required in response to a video mode 
  5725. switch in a background VDM, which would place the VDM in a video mode not 
  5726. supported when running in the background. 
  5727.  
  5728.  
  5729. ΓòÉΓòÉΓòÉ 15.5.4. Timer/Priority Services ΓòÉΓòÉΓòÉ
  5730.  
  5731. Timer services are provided to support the virtual programmable interrupt 
  5732. controller in the event of a time out occurring in an interrupt handler. 
  5733. Priority services are also used by VPIC to handle VDM scheduling priority. 
  5734.  
  5735.  
  5736. ΓòÉΓòÉΓòÉ 15.5.5. Page Fault Services ΓòÉΓòÉΓòÉ
  5737.  
  5738. A virtual device driver may register its own handler for page fault exceptions, 
  5739. in order to handle such events in an orderly manner.  VDH services are provided 
  5740. in order to support this registration. 
  5741.  
  5742.  
  5743. ΓòÉΓòÉΓòÉ 15.5.6. Other Services ΓòÉΓòÉΓòÉ
  5744.  
  5745.  Error message and display 
  5746.  Terminate VDM service 
  5747.  
  5748.  
  5749. ΓòÉΓòÉΓòÉ 15.5.7. VDH Functions ΓòÉΓòÉΓòÉ
  5750.  
  5751. The following list summarizes most of the VDH functions: 
  5752.  
  5753. VDH API                    Description 
  5754. VDHAllocDosMem             Reserve memory for stub DOS device driver 
  5755. VDHAllocMem                Allocate small buffers 
  5756. VDHAllocPages              Allocate linear space and commit backing storage 
  5757. VDHArmReturnHook           Used to catch return from a VDHPushFarCall 
  5758. VDHArmSTIHook              Receive control when current DOS session enables 
  5759.                            simulated interrupts 
  5760. VDHClearVIRR               Clear interrupt request flag 
  5761. VDHClearSem                Used to protect global structures 
  5762. VDHCloseVDD                Terminate communication between virtual device 
  5763.                            driver and physical device driver 
  5764. VDHCopyMem                 Used by the EMM copy service and to copy device 
  5765.                            driver stub to VDM 
  5766. VDHExchangeMem             Used by the EMM exchange service 
  5767. VDHFindFreePages           Find a region of free linear space below 1MB + 64KB 
  5768. VDHFreeMem                 Deallocate small buffers 
  5769. VDHFreePages               Deallocate memory objects 
  5770. VDHGetDirtyPageInfo        Read and clear dirty-page bits (Dirty bits indicate 
  5771.                            whether a page has been written to) 
  5772. VDHInstallFaultHook        Install hook for page faults 
  5773. VDHInstallIntHook          Used to hook INT 67h (EMS interrupt) 
  5774. VDHInstallUserHook         Register to get notification about VDM creation and 
  5775.                            termination 
  5776. VDHLockMem                 Verifies that a specified memory region is available 
  5777.                            and locks it 
  5778. VDHMapPages                Used to map EMS windows to EMS objects or to unmap 
  5779.                            pages 
  5780. VDHNotIdle                 Resets VDHPostIdle 
  5781. VDHOpenVDD                 Establish communication between virtual device 
  5782.                            driver and physical device driver 
  5783. VDHOpenVIRQ                Returns an IRQ handle for use with the other VPIC 
  5784.                            services 
  5785. VDHPopInt                  Remove ROM return address from user's CS:IP 
  5786. VDHPostIdle                Put VDM into sleeping state. 
  5787. VDHPushFarCall             Used by the EMM map and call service 
  5788. VDHPushInt                 Change control to the V86-interrupt handler 
  5789. VDHQueryConfigString       Used to retrieve configuration data strings 
  5790. VDHQueryFreePages          Determine amount of free virtual memory 
  5791. VDHQuerySysValues          Determine VDM conventional memory size 
  5792. VDHReallocPage             Change previous page allocation 
  5793. VDHRequestSem              Used to protect global data 
  5794. VDHRequestVDD              Requests the operation of a VDD 
  5795. VDHReservePage             Reserve region of linear space below 1MB + 64KB 
  5796. VDHSetDOSDevic             Register DOS device driver 
  5797. VDHSetVIRR                 Set interrupt request flag 
  5798. VDHUnreservePages          Unreserve region of linear space below 1MB + 64KB 
  5799. VDHWakeIdle                Awake VDM from sleeping state 
  5800. VDHYield                   Yield the processor to any other thread of equal or 
  5801.                            higher priority 
  5802.  
  5803. These functions are only valid when issued from within a module executing at 
  5804. privilege level 0; they cannot be issued by normal protected mode application 
  5805. processes. 
  5806.  
  5807.  
  5808. ΓòÉΓòÉΓòÉ 15.6. VDM Termination ΓòÉΓòÉΓòÉ
  5809.  
  5810. Virtual device drivers are responsible for a number of actions upon termination 
  5811. of a VDM. The nature of these actions is largely dependent on whether the VDM 
  5812. terminates normally or abnormally. 
  5813.  
  5814.  
  5815. ΓòÉΓòÉΓòÉ 15.6.1. Normal Termination ΓòÉΓòÉΓòÉ
  5816.  
  5817. A virtual device driver typically registers a VDM_TERMINATE hook with the 
  5818. Virtual DOS Machine Manager, which causes the virtual device driver to be 
  5819. informed when a VDM is terminated.  When the VDM_TERMINATE hook is called, the 
  5820. virtual device driver is responsible for freeing all resources allocated on 
  5821. behalf of the terminating VDM. 
  5822.  
  5823.  
  5824. ΓòÉΓòÉΓòÉ 15.6.2. Abnormal Termination ΓòÉΓòÉΓòÉ
  5825.  
  5826. Virtual device drivers may experience a number of different error conditions, 
  5827. and must be able to act in order to recover from such errors where possible. 
  5828.  
  5829. Errors Returned from VDH Services 
  5830.  
  5831. Requests for VDH services may be refused by the operating system or may fail 
  5832. due to lack of resources.  For example, a call to VDHAllocMem() may return 0, 
  5833. indicating that the memory allocation request cannot be satisfied. 
  5834.  
  5835. During initialization of the virtual device driver or creation of a VDM such an 
  5836. error would cause the initialization or creation to be terminated. During 
  5837. execution of a DOS application, the virtual device driver should return control 
  5838. to the application, indicating the failure of the requested application 
  5839. service.  If this cannot be done, the VDM must be terminated. 
  5840.  
  5841. Bad Parameter Passed to VDH Service 
  5842.  
  5843. A virtual device driver may make a service request with bad data, typically due 
  5844. to a bug in the device driver code; such events are likely during development 
  5845. and testing.  For example, the virtual device driver may attempt to issue a 
  5846. VDHFreeMem() function call specifying an address which was not previously 
  5847. allocated using VDHAllocMem(). 
  5848.  
  5849. Such errors are costly; since virtual device drivers operate at privilege level 
  5850. 0 and hence have access to all code and data in the system, it is impossible to 
  5851. localize the effect to a single VDM, or to be certain that the event has not 
  5852. corrupted data or control structures in the operating system kernel.  In such 
  5853. cases, the Virtual DOS Machine Manager will halt the system. 
  5854.  
  5855. Virtual Device Driver Consistency Failures 
  5856.  
  5857. A virtual device driver may detect inconsistencies within its own state 
  5858. information.  Such inconsistencies may be experienced in either global or 
  5859. instance state data.  The virtual device driver must inform the user of the 
  5860. error.  If the error can be isolated to the instance data of a single VDM, that 
  5861. VDM must be terminated.  If the error is in global state data, it will be 
  5862. necessary to halt the system. 
  5863.  
  5864. Note that halting the entire system is highly unfriendly behavior on the part 
  5865. of a virtual device driver.  Very rarely, if ever, should such action become 
  5866. necessary.  A virtual device driver should take all possible steps to isolate 
  5867. any state inconsistencies to a single VDM only. 
  5868.  
  5869. Illegal Operation by a DOS Application 
  5870.  
  5871. DOS applications running in VDMs may issue illegal instructions.  For example, 
  5872. a DOS application may issue an OUT instruction to a port controlled by the 
  5873. virtual disk device driver, which does not support direct hardware control of 
  5874. the disk controller. 
  5875.  
  5876. In such cases, the virtual device driver must inform the user of the error 
  5877. condition and either ignore the error or terminate the VDM and the application 
  5878. within it. 
  5879.  
  5880.  
  5881. ΓòÉΓòÉΓòÉ 15.7. Summary ΓòÉΓòÉΓòÉ
  5882.  
  5883. OS/2 Version 2.0 provides device drivers to handle the interface between the 
  5884. operating system and the hardware.  Physical device drivers are used by normal 
  5885. protected mode processes running OS/2 applications, while virtual device 
  5886. drivers are used by DOS applications running in virtual DOS machines. 
  5887.  
  5888. Virtual device drivers provide a means of representing hardware devices to a 
  5889. DOS application in a virtual DOS machine, such that the devices appear to the 
  5890. application as though the application had sole control over the device.  In 
  5891. this way, MVDM allows DOS applications to issue instructions which directly 
  5892. manipulate hardware devices or the DOS system environment, while maintaining 
  5893. full protection of other applications in the system.  Virtual device drivers 
  5894. typically access hardware by requesting services from physical device drivers. 
  5895.  
  5896. Virtual device drivers are used not only for shared hardware devices, but also 
  5897. for other aspects of the machine environment, such as BIOS, CMOS, and the 
  5898. (physical) programmable interrupt controller.  Through the use of virtual 
  5899. device drivers for these components, DOS applications may freely access and 
  5900. manipulate them without affecting other DOS applications or OS/2 applications 
  5901. in the system. 
  5902.  
  5903. OS/2 Version 2.0 provides a number of standard virtual device drivers for the 
  5904. DOS system environment and common hardware devices.  Hardware vendors may 
  5905. develop virtual device drivers for their own hardware adapters.  Note that if a 
  5906. hardware device will be dedicated to one application (that is, sharing of the 
  5907. hardware is not required) then a virtual device driver is not needed; the 
  5908. normal DOS device driver will allow the application to access the hardware 
  5909. device as in a native DOS environment. 
  5910.  
  5911. A virtual device driver operates at privilege level 0, and therefore cannot 
  5912. access operating system services via the normal application programming 
  5913. interfaces provided by OS/2 Version 2.0.  Instead, a set of virtual device 
  5914. helper services is provided to enable virtual device drivers to access system 
  5915. services.  Virtual device drivers may be written in a high-level language such 
  5916. as "C". 
  5917.  
  5918.  
  5919. ΓòÉΓòÉΓòÉ 16. Memory Extender Support ΓòÉΓòÉΓòÉ
  5920.  
  5921. Many popular DOS applications use memory extenders such as EMS and/or XMS to 
  5922. gain access to memory above the 1MB real mode addressing limit on the 80286, 
  5923. 80386, or 80486 processors.  Such extenders allow DOS applications to have 
  5924. total code and data spaces larger than the available base memory, and to have 
  5925. very large code or data objects loaded into memory for enhanced execution 
  5926. speed.  The standard configuration of OS/2 Version 2.0 provides both LIM EMS 
  5927. Version 4.0 (which includes backward compatibility with LIM Version 3.X) and 
  5928. LIMA XMS Version 2.0 functions for DOS applications running in virtual DOS 
  5929. machines. 
  5930.  
  5931. Figure "General Overview of Different Types of Memory for DOS Applications" 
  5932.  
  5933. This chapter describes the implementation of EMS and XMS support for virtual 
  5934. DOS machines.  For those readers not already familiar with the architecture of 
  5935. these memory extenders, an overview is provided in Memory Extender 
  5936. Architectures. 
  5937.  
  5938.  
  5939. ΓòÉΓòÉΓòÉ 16.1. Expanded Memory Support ΓòÉΓòÉΓòÉ
  5940.  
  5941. OS/2 Version 2.0 supports expanded memory according to the LIM EMS Version 4.0. 
  5942. Under DOS, special hardware is normally required to support EMS, although a 
  5943. number of software-based EMS emulation packages exist.  MVDM supports EMS by 
  5944. mapping memory allocation requests into the linear process address space, using 
  5945. normal system memory.  Hence no special hardware or software is required. 
  5946.  
  5947. The OS/2 Version 2.0 LIM EMS emulation provides the following function: 
  5948.  
  5949.  Implements all the required functions in the LIM EMS Version 4.0. 
  5950.  
  5951.  Provides each VDM with a separate EMS emulation.  Each VDM has its own set of 
  5952.   expanded objects so that features like interprocess communication work as 
  5953.   they would if each VDM were running on a different real 80386. Each VDM 
  5954.   cannot affect the availability of objects in other VDMs or access memory in 
  5955.   other VDMs. 
  5956.  
  5957.  Provides for remapping of conventional memory (below 640KB) for use by 
  5958.   programs like Windows 2.0. 
  5959.  
  5960.  Provides configurable limits for how much EMS memory is available across 
  5961.   VDMs, as well as a limit per VDM.  The DOS Settings feature allows the user 
  5962.   to override the per-VDM  limit, subject to the constraint given by the 
  5963.   overall limit. 
  5964.  
  5965.  Supports multiple physical to single logical mappings.  Different 8086 
  5966.   addresses can map to the same expanded memory object address. This is 
  5967.   required by programs like Lotus 1-2-3. 
  5968.  
  5969.  EMS can be removed and the operating system can run without loading EMS in 
  5970.   any VDM session. 
  5971.  
  5972. Memory objects are mapped into the V86 mode address space (below 1MB), so DOS 
  5973. applications can access very large address spaces.  Applications access EMS 
  5974. services using the DOS interrupt INT 67h. 
  5975.  
  5976.  
  5977. ΓòÉΓòÉΓòÉ 16.1.1. Virtual Expanded Memory Manager ΓòÉΓòÉΓòÉ
  5978.  
  5979. EMS services are implemented under MVDM using a virtual device driver known as 
  5980. the Virtual Expanded Memory Manager (VEMM), which offers a separate EMS 
  5981. emulation to each VDM. This implementation is accomplished by placing most VEMM 
  5982. control structures in a per-VDM data area outside the V86 mode address space. 
  5983. Each VDM has up to 255 handles, 15 alternate register sets, remappable 
  5984. conventional memory for operating system use, and a 16KB "raw" block size. 
  5985.  
  5986. VEMM prehooks interrupt vector 67h through a VDH service to catch software 
  5987. interrupts for EMS services.  Prehooking means that VEMM gains control before 
  5988. the V86 mode interrupt vector is called. VEMM also provides a V86 mode stub 
  5989. driver used to indicate to DOS applications that EMS is available. This stub 
  5990. must hook INT 67h so that applications can find a particular string in the 
  5991. header to determine if EMS is available. When, as in the typical case, 
  5992. applications have not also hooked INT 67h, VEMM handles service requests at 
  5993. prehook time. When INT 67 has been hooked, VEMM handles requests when the 
  5994. stub's hook calls it by doing an INT 67h from inside the stub. 
  5995.  
  5996. To prevent VDM's from grabbing large amounts of EMS memory, there is a 
  5997. configurable default per VDM limit.  VEMM depends heavily upon the memory 
  5998. manager. EMS object allocation, reallocation, or deallocation is accomplished 
  5999. by requesting corresponding services from VDH services. Most VEMM creation time 
  6000. setup is postponed until the first INT 67h service request is made. Figure 
  6001. "Expanded Memory Manager Control Flow" shows the flow of control when a DOS 
  6002. application makes an EMS service request from within a VDM: 
  6003.  
  6004.  1. INT 67h service requests are trapped by the Virtual DOS Machine Manager and 
  6005.     routed to VEMM. 
  6006.  
  6007.  2. The VEMM makes the appropriate requests to VDH services to allocate or 
  6008.     manipulate the EMS object. 
  6009.  
  6010. Expanded Memory Manager Control Flow 
  6011.  
  6012. During the initialization of the VDM the VDM Manager loads and initializes the 
  6013. EMS DOS stub device driver into the VDM address space. 
  6014.  
  6015. The VDM Application can use either of two methods to test for the existence of 
  6016. the VEMM: 
  6017.  
  6018.  1. Issue an open request (INT 21h Function 3DH) using the guaranteed device 
  6019.     name of the VEMM driver. If the open function succeeds, either the driver 
  6020.     is present or a file with the same name coincidentally exists on the 
  6021.     default disk drive. To rule out the latter, the application can use 
  6022.     IOCTL(INT 21h Function 44H) subfunctions 00h and 07h to ensure that VEMM is 
  6023.     present. Don't forget to use INT 21H Function 3Eh to close the handle that 
  6024.     was obtained from the open function, so that the handle can be reused for 
  6025.     another file or device. 
  6026.  
  6027.  2. Look for a special signature in the EMS DOS stub device driver which 
  6028.     signals the VDM Application that EMS is available. This search is done by 
  6029.     using the address that is found in the INT 67h vector to inspect the device 
  6030.     header of the presumed VEMM which is, in this case, the fooling EMS DOS 
  6031.     stub device driver. Interrupt handlers and device drivers must use this 
  6032.     method. If the VEMM seems to be present, the name field at a special offset 
  6033.     of the device header contains a special string. This method is not only 
  6034.     avoiding the relatively high overhead of an VDM DOS open function but is 
  6035.     nearly foolproof. However, it is somewhat less well behaved because it 
  6036.     involves inspection of memory that does not belong to the application. 
  6037.  
  6038.     The only task of the EMS DOS stub device driver is to tell the VDM DOS 
  6039.     application that EMS is available. As soon as this is done the regular EMS 
  6040.     business can start as explained in the following points: 
  6041.  
  6042.  1. The VDM Application issues a INT 67h service request. 
  6043.  
  6044.  2. The VDM Manager loads the VEMM. 
  6045.  
  6046.  3. The VDM Manager initialization, creation, termination calls for 
  6047.     EMM-objects. 
  6048.  
  6049.  4. The VDM Manager traps the VDM application's INT 67h service request and 
  6050.     routes it to VEMM. 
  6051.  
  6052.  5. The VDM callback for V86 call with far return. 
  6053.  
  6054.  6. The VEMM requests corresponding services from the VDH services: 
  6055.  
  6056.     Creation/termination handler registration 
  6057.  
  6058.     INT 67h pre-hooking 
  6059.  
  6060.     Linear address reservation 
  6061.  
  6062.     Memory management. 
  6063.  
  6064.  7. The result is returned. 
  6065.  
  6066. This constellation also allows a VDM application to hook INT 67h. 
  6067.  
  6068. Note that unlike most virtual device drivers, VEMM does not have a 
  6069. corresponding physical device driver.  Instead, VEMM manages its memory using 
  6070. the OS/2 Version 2.0 operating system kernel's memory management services. EMS 
  6071. object allocation, reallocation, or deallocation is accomplished by requesting 
  6072. corresponding services from the operating system's memory manager.  For 
  6073. example, when an application requests the allocation of an expanded memory 
  6074. object, VEMM asks the memory manager to allocate a memory object in linear 
  6075. memory outside any VDM. 
  6076.  
  6077. Structure 
  6078.  
  6079. The VEMM module consists of: 
  6080.  
  6081.  An Initialization Component that determines the default size at boot time 
  6082.  
  6083.  A Creation Component that initializes per-VDM structures when a VDM is 
  6084.   created 
  6085.  
  6086.  A Router that decodes application INT 67h (and routes the call to a service 
  6087.   routine) and 30 service routines with associated sub-services. 
  6088.  
  6089. Each VDM has a 255-entry EMS handle table used to keep track of the size and 
  6090. allocation of expanded memory objects, 16 register sets that indicate which 
  6091. parts of the expanded objects are mapped into the VDM address space, and save 
  6092. tables to save register set contents.  Only one register set is active at a 
  6093. time.  That active register set indicates the actual page table contents. 
  6094. Switching register sets or restoring a saved register set resets all aliases in 
  6095. the windows to those indicated by the new register set.  Unmapped pages are set 
  6096. to "black hole" memory.  The memory manager's page size for all these 
  6097. operations is 4KB.  VEMM makes the adjustment for its 16KB page size. 
  6098.  
  6099. Initialization 
  6100.  
  6101. VEMM is typically installed at system initialization time, via a DEVICE= 
  6102. statement in CONFIG.SYS, as shown below: 
  6103.  
  6104. DEVICE=C:\OS2\MDOS\VEMM.SYS 4096, 2048
  6105.  
  6106. To prevent VDMs from using all available memory, there is an overall limit on 
  6107. the amount of EMS memory, and a default limit for each VDM to prevent a VDM 
  6108. from requesting all available EMS memory.  The defaults for these limits are 
  6109. specified in the DEVICE= statement for VEMM.  The default limit for each VDM 
  6110. may be overridden using the DOS Settings feature. 
  6111.  
  6112. Setting the overall limit to zero disables EMS in all VDMs, regardless of the 
  6113. per-VDM value.  Setting the per-VDM value to zero disables EMS in all VDMs 
  6114. unless their entries on the Presentation Manager desktop specify a non-zero EMS 
  6115. size.  Setting the EMS size to zero for an entry on the desktop disables EMS 
  6116. for that application only.  Most users need never change the default value. 
  6117. DOS settings for frame position, and the size of extra mapping regions above 
  6118. and below 640KB may be configured by the user; see DOS Settings. 
  6119.  
  6120. Upon installation, an initialization routine within VEMM supplies the entry 
  6121. point addresses of VEMM creation and close routines to the Virtual DOS Machine 
  6122. Manager. 
  6123.  
  6124. Most VEMM setup is postponed until the first INT 67H service request is made. 
  6125. Only remappable conventional memory is set up before that time. This assures 
  6126. that other virtual device drivers have a chance to reserve ROM and device 
  6127. memory areas. 
  6128.  
  6129. VDM Creation 
  6130.  
  6131. Upon creation of a VDM, a VDH service is used to get the EMS size for that VDM. 
  6132. This will return a string if the DOS program's entry on the desktop has an 
  6133. associated EMS size.  If not defined, the default size retrieved from 
  6134. CONFIG.SYS at system initialization is used.  If EMS size is not zero, the 
  6135. following steps are then performed: 
  6136.  
  6137.  1. Two mappable windows are located and reserved. 
  6138.  
  6139.  2. Memory is mapped into the low window. 
  6140.  
  6141.  3. Interrupt 67h is hooked using a VDH service. 
  6142.  
  6143.  4. The V86 mode device driver stub is loaded. 
  6144.  
  6145.  5. An initial block of the handle table is allocated. 
  6146.  
  6147. Upon VDM creation, VEMM allocates a block of memory in the area between 256KB 
  6148. and RMSIZE [The RMSIZE statement in CONFIG.SYS specifies the maximum size of a 
  6149. VDM's address space; values up to 640KB are allowed. ] and maps it into the VDM 
  6150. address space.  VEMM requests VDH services to locate the largest free address 
  6151. range in the V86 mode address space above 640KB that is available for the 
  6152. mappable window.  VEMM then reserves the largest range available that is at 
  6153. least 64KB and no more than 128KB in size, and is a multiple of 16KB.  If an 
  6154. extended BIOS data area is present, the returned free range will be below this 
  6155. area so that BIOS cannot be inadvertently mapped away. 
  6156.  
  6157. Waiting until creation time to reserve this memory allows virtual device 
  6158. drivers with actual hardware to claim their addresses first, since VEMM can 
  6159. place its memory at any available address.  A consequence of this technique is 
  6160. that the space is reserved only for the VDM being created. It could be in a 
  6161. different location or be a different size for other VDMs. 
  6162.  
  6163. VEMM performs mapping by requesting the operating system's memory manager to 
  6164. alias linear space inside a mappable window in the V86 mode address space to a 
  6165. memory region outside the V86 address space.  The application can then access 
  6166. this part of the expanded memory object. 
  6167.  
  6168. The VEMM virtual device driver prehooks interrupt vector 67h through a VDH 
  6169. service to catch software interrupts for EMS services.  Prehooking means that 
  6170. VEMM gains control before the V86 mode interrupt vector is called. VEMM also 
  6171. provides a stub driver, the sole function of which is to indicate to DOS 
  6172. applications that EMS is available. 
  6173.  
  6174. VEMM then arranges for the loading of a stub device driver in the VDM. This 
  6175. driver provides a header within the V86 mode address space which can be read by 
  6176. an application searching for the name of the real mode EMS driver.  It also 
  6177. responds to a few simple requests made to its strategy routine, basically 
  6178. replying that it is present and ready.  The stub driver does not actually 
  6179. process EMS service requests; these are handled by VEMM. 
  6180.  
  6181. Routing 
  6182.  
  6183. The router receives notification from the Virtual DOS Machine Manager when an 
  6184. application issues an INT 67h request.  The router checks the request to ensure 
  6185. that it is valid, and then causes an exception which is routed to the Virtual 
  6186. DOS Machine Manager.  The Virtual DOS Machine Manager then reflects the 
  6187. interrupt back into the VDM's interrupt vector table.  This technique is 
  6188. necessary since interrupt vector hooks are only allowed after application code 
  6189. has been executed.  The V86 mode interrupt vector for INT 67h causes another 
  6190. exception which is routed to the Virtual DOS Machine Manager which then calls 
  6191. VEMM. 
  6192.  
  6193. The EMS Alter Map and Call service allows an application to have VEMM remap 
  6194. memory to place a routine within the V86 mode address space, call that routine 
  6195. and then remap memory to its previous state again after the routine issues a 
  6196. far return.  This call can occur recursively; the application code that is 
  6197. called can in turn use the Alter Map and Call service. 
  6198.  
  6199. VEMM does the initial remapping and stores the after-call remapping information 
  6200. on the client's stack.  VDH services are used to call the application's routine 
  6201. and intercept the return.  VEMM supplies the Virtual DOS Machine Manager with a 
  6202. V86 mode address to call and a VEMM handler which is invoked when the 
  6203. application routine does a far return.  After the routine returns, VEMM 
  6204. restores the original mapping saved on the client's stack. 
  6205.  
  6206. The Remap and Jump service is similar but does not require interception of an 
  6207. application routine's return or the saving of a mapping.  Remapping is done and 
  6208. the CS:IP is changed to jump to the address provided by the application. 
  6209.  
  6210. Information calls involve at most a quick search of structures.  Structures are 
  6211. maintained to provide information about handles, allocations, and VEMM 
  6212. capabilities.  Handle directory services are also provided.  The number of 
  6213. pages VEMM reports as available is the minimum of the number of pages the VDM 
  6214. has left in VEMM pages and the amount the memory manager estimates is 
  6215. available. 
  6216.  
  6217. Protection 
  6218.  
  6219. A pseudo-random key is produced with the first protection call made by a VDM 
  6220. and also for the first protection call made after a key was returned. This key 
  6221. is given to the application which made the call that caused its generation. 
  6222. OSEnabled can be reset only by the owner of the key.  The key owner can also 
  6223. return the key.  OSEnabled indicates whether or not protected functions can be 
  6224. executed.  The key will be generated by operations on the current time to 
  6225. ensure that the key changes, even for multiple calls between successive timer 
  6226. ticks. 
  6227.  
  6228.  
  6229. ΓòÉΓòÉΓòÉ 16.1.2. EMS Object Mapping ΓòÉΓòÉΓòÉ
  6230.  
  6231. Mappable windows are located by asking the Virtual DOS Machine Manager to 
  6232. provide free linear regions after other virtual device drivers have claimed the 
  6233. address ranges required for their hardware.  The base window (region from 256KB 
  6234. to RMSIZE) is mapped to an expanded object at VDM  creation time.  This window 
  6235. is used as normal memory by DOS or DOS applications, but can also be remapped 
  6236. by applications that wish to do so. 
  6237.  
  6238. Some applications assume mappable regions begin on 17KB boundaries, although 
  6239. this is not part of the EMS specification.  OS/2 Version 2.0 follows this 
  6240. undocumented convention. 
  6241.  
  6242. There are multiple techniques for saving and restoring mappings in LIM. Save 
  6243. tables and copies of parts of register sets copied to application memory can be 
  6244. used to save and restore mappings.  All contain a pairing of physical segment 
  6245. and <handle, logical page> pairs.  Saving of mappings is done by segment, 
  6246. handle, and logical page entries to the buffer in which the save is performed. 
  6247. For saves that save the entire mapping, the register index need not be stored. 
  6248. Mappings are restored by making a set of aliasing calls to the memory manager, 
  6249. and copying the new mapping into the active register set. 
  6250.  
  6251. Illegal mappings are mapped to black hole pages. A black hole page is a page 
  6252. that does not cause faults, but which need not store values written to it. 
  6253. Black hole pages can be implemented as invalid addresses that float on the bus, 
  6254. ROM pages if there is no ROM caching, a wasted physical memory page, or a 
  6255. discardable page. 
  6256.  
  6257. Structures returned to the client will use physical pages rather than segments 
  6258. since these are smaller for the client to store and are simpler to check for 
  6259. validity when restored.  All save structures held by the V86 client use a 
  6260. checksum to detect tampering by the V86 client. 
  6261.  
  6262. LIM allows an application to reallocate the special handle that contains 
  6263. conventional memory, thus allowing the expanded memory to be reused.  This is 
  6264. supposed to be done only by an operating system program that knows the special 
  6265. handle is handle 0, but may conceivably be done by any application. Note that 
  6266. applications can deallocate the DOS memory area.  If they do this and fail to 
  6267. restore it, COMMAND.COM is unable to reload and the VDM will terminate.  This 
  6268. behavior is identical to a native DOS environment. 
  6269.  
  6270. Register Sets 
  6271.  
  6272. Application requests to map pages into a register set are handled by storing 
  6273. the new mappings in the register set data structure.  A call is made to the 
  6274. memory manager to alias pages or set them to a black hole for unmapped pages. 
  6275.  
  6276. The current register set is changed to a new register set by aliasing linear 
  6277. memory through memory manager calls according to the new registers and changing 
  6278. the current register set variable.  Other calls allow saving and restoring 
  6279. register sets from an application-supplied array similar to Save/Restore above. 
  6280.  
  6281. Allocating/Deallocating Objects 
  6282.  
  6283. Upon receiving an application request to allocate, reallocate, or deallocate an 
  6284. EMS object, VEMM transforms the request into corresponding calls to the OS/2 
  6285. Version 2.0 memory manager.  Each EMS object is allocated as a separate memory 
  6286. object in a linear address range in the VDM's process address space, but 
  6287. outside the V86 mode address space.  The memory manager returns the start 
  6288. address and size of each EMS object to VEMM, which then updates its EMS handle 
  6289. table accordingly. 
  6290.  
  6291. Allocations are made by selecting a free EMS object handle; a free handle has a 
  6292. start address of zero.  VEMM then requests the memory manager to allocate the 
  6293. required memory, and records the start address and size of the object as 
  6294. returned by the memory manager.  The total allocation size for each VDM and the 
  6295. total allocations across all VDMs are maintained so that the maximum allocation 
  6296. size is not exceeded.  If an allocation is of size zero, no actual allocation 
  6297. is made and a non-zero address and zero size are recorded in the handle entry. 
  6298.  
  6299. When a deallocation request is made, the address in the handle is changed to 0 
  6300. and the memory manager is called to free the allocation.  Reallocation requests 
  6301. are serviced by passing on the request to a VDH service and recording the new 
  6302. size and start address.  Since reallocations may lead to object movement, pages 
  6303. mapped from the object are unmapped before reallocation and remapped afterward. 
  6304.  
  6305. When an application reallocates to zero, VEMM has the memory manager deallocate 
  6306. the memory object, and changes the handle table entry so it has zero pages with 
  6307. a meaningless non-zero address to indicate the handle is still in use.  Objects 
  6308. of size zero are allowed in VEMM, but not in OS/2, so VEMM will free the memory 
  6309. but retain its own data for the object handle. When a non-zero reallocation is 
  6310. performed on the object, a new object is transparently allocated. 
  6311.  
  6312. LIM allows an application to deallocate memory that is mapped into the current 
  6313. register set, alternate register sets, or save maps (all internal structures 
  6314. that save mappings).  EMS is silent about what should happen if an application 
  6315. touches this mapped memory after deallocation.  Since 8086 applications are 
  6316. generally allowed to search through the address space without harm, these 
  6317. deallocated pages should be remapped to a black hole. 
  6318.  
  6319. Searching through all 255 SaveMaps and 15 non-current register sets is 
  6320. expensive even with optimizations.  Exhaustive search slows deallocations and 
  6321. shrinking reallocations, and keeping track of the locations of mappings slows 
  6322. mapping operations.  Therefore, upon deallocation or shrinking reallocation, 
  6323. only the current register set is checked for deallocated pages.  Stored 
  6324. registers (255 SaveMaps and 15 RegSets for the VDM) will not be checked until 
  6325. they are reactivated.  When an invalid page is found during remapping, it is 
  6326. simply remapped to the black hole. 
  6327.  
  6328.  
  6329. ΓòÉΓòÉΓòÉ 16.1.3. Per-VDM Data Allocation ΓòÉΓòÉΓòÉ
  6330.  
  6331. Handle table entries, register sets, save tables, and handle names all require 
  6332. a good deal of space if used fully.  Most of these data structures typically do 
  6333. not require their maximum possible size.  For this reason, they are allocated 
  6334. dynamically by VEMM in order to reduce memory utilization. 
  6335.  
  6336. Memory for a register set is allocated when clients allocate the register set. 
  6337. An array of 16 pointers will address buffers for allocated register sets; these 
  6338. pointers are null for free register sets that applications may yet allocate. 
  6339.  
  6340. The handle table, handle name table, and save tables are all allocated with a 
  6341. directory structure.  A directory is an array of pointers to allocation blocks; 
  6342. each allocation block contains enough space for multiple entries. This allows a 
  6343. specific entry to be found by specifying the block and entry offset within the 
  6344. block.  Since each can have at most 255 entries, both the block and offset can 
  6345. fit in a single byte. 
  6346.  
  6347. An allocated handle entry contains an index for its associated save table or 
  6348. name (if used).  For unallocated objects, the index is zero.  The smallest free 
  6349. handle will be allocated when a handle is needed, thus requiring less memory to 
  6350. be allocated for the handle table. 
  6351.  
  6352. The name table is kept in packed form.  When an entry is freed, the last entry 
  6353. is moved into the free hd, thus reducing space requirements. 
  6354.  
  6355. Save table entries are larger and generally have short lifetimes.  These will 
  6356. be allocated in the same way handles are allocated (that is, where the smallest 
  6357. available is allocated first).  For all three of these tables, when new entries 
  6358. are needed and all blocks are full, a new block is allocated. 
  6359.  
  6360.  
  6361. ΓòÉΓòÉΓòÉ 16.1.4. Problems with Expanded Memory ΓòÉΓòÉΓòÉ
  6362.  
  6363. EMS requires a 64KB block of contiguous free memory in the address range 640KB 
  6364. to 1MB for its page frame. As we can see from Figure "General Overview of 
  6365. Different Types of Memory for DOS Applications" this memory range is shared 
  6366. with BIOS, hardware buffers and device drivers. If your application reports 
  6367. that no EMS memory is available, even if you have used the DOS Settings option 
  6368. EMS_MEMORY_LIMIT to set a non-zero value, it could be that a 64KB page frame 
  6369. location could not be found. See Expanded Memory (EMS) and Upper Memory (UMB) 
  6370. on how to resolve this contention. 
  6371.  
  6372. If a program returns an error due to insufficient expanded memory, the 
  6373. following points should be addressed: 
  6374.  
  6375.  Ensure that CONFIG.SYS and/or AUTOEXEC.BAT do not start unnecessary programs 
  6376.   that use expanded memory. 
  6377.  
  6378.  Change the DEVICE= statement for VEMM.SYS in CONFIG.SYS to provide more 
  6379.   expanded memory to every VDM.  Alternatively, use the EMS Memory Size DOS 
  6380.   Settings to allocate more memory to a specific VDM.  See DOS Settings. 
  6381.  
  6382. VEMM for OS/2 was designed to install for EMS only when the DOS application 
  6383. makes its first EMS request. This was done for two reasons. First, it saves 
  6384. time and memory. Second, it gives the DOS drivers or applications a chance to 
  6385. access adapters in the EMS page frame address space. OS/2 V2.0 will recognize 
  6386. adapters with the ROM signature header, but will not see adapter RAM/MMPIO 
  6387. areas. 
  6388.  
  6389. VEMM determines that it has space available during DOS Session creation but a 
  6390. DOS program/driver could cause EMS to not install by accessing memory in the 
  6391. page frame before calling the EMS driver. Lotus 1-2-3 Version 2.3 was found to 
  6392. access the adapter space BEFORE calling EMS. On some machines, this caused no 
  6393. EMS to be present for Lotus 1-2-3. 
  6394.  
  6395. To satisfy this situation, VEMM has than been changed (after GA) to not wait 
  6396. for the first EMS call. This should clear up the EMS problems related to 
  6397. programs accessing the adapter address space (X'C0000'-X'E0000'). However, it 
  6398. should be known that it is now possible for VEMM to claim areas that could 
  6399. actually be adapter address space. In general, the user should be aware of this 
  6400. situation. To resolve this we suggest to use the MEM_EXCLUDE property to force 
  6401. EMS not to use the desired address space. 
  6402.  
  6403.  
  6404. ΓòÉΓòÉΓòÉ 16.2. Expanded Memory (EMS) and Upper Memory (UMB) ΓòÉΓòÉΓòÉ
  6405.  
  6406. The following section applies to both VDM DOS Emulation and DOS VMB. 
  6407.  
  6408. Expanded Memory Specification (EMS) is discussed in detail in Memory Extender 
  6409. Support. One requirement of EMS is a page frame in real memory between 640KB 
  6410. and 1MB (hex addresses X'A0000' to X'FFFFF'). Since IBM systems reserve 
  6411. addresses X'A0000' to X'BFFFF' for video, and X'E0000' to X'FFFFF' for BIOS, 
  6412. the EMS page frame is normally restricted to addresses between X'C0000' and 
  6413. X'E0000'. This area can also be used for Upper Memory Blocks, where DOS device 
  6414. drivers and resident programs can be loaded. This frees up valuable space below 
  6415. 640KB for conventional DOS programs. 
  6416.  
  6417. Unfortunately, memory between X'C0000' and X'E0000' is also needed for Option 
  6418. Adapter ROM and RAM. Indeed it can be difficult or even impossible to configure 
  6419. EMS on a system which has several intelligent adapters installed. 
  6420.  
  6421. There is really no solution to this problem (sometimes known as "RAM Cram") 
  6422. under DOS. However OS/2 Version 2.0 provides an elegant alternative. 
  6423.  
  6424. Normally a VDM inherits a memory map which mirrors the actual system hardware 
  6425. configuration; adapter ROM and RAM addresses set by the PS/2 Reference Diskette 
  6426. (or adapter switches on non-Micro Channel systems) are mapped into the VDM 
  6427. address space and are not available for EMS or UMBs. 
  6428.  
  6429. But since the VDM occupies virtual memory this can easily be changed. The DOS 
  6430. Settings value MEM_INCLUDE_REGIONS parameter releases adapter addresses for use 
  6431. as EMS or UMBs. In most cases this can be set to the complete X'C0000'-X'DFFFF' 
  6432. range. 
  6433.  
  6434. If a VDM uses an adapter directly (usually via a DOS device driver), the 
  6435. adapter ROM or RAM address must not be specified in MEM_INCLUDE_REGIONS. 
  6436. Addresses of adapters used indirectly by the VDM (through OS/2 Version 2.0) may 
  6437. be included. For example, the full X'C0000'to X'DFFFF' range may be included on 
  6438. a SCSI-based PS/2, even though the SCSI adapter ROM may occupy X'D8000' to 
  6439. X'DFFFF'. The DOS VDM does not directly access the SCSI adapter so it does not 
  6440. need SCSI ROM mapped into its address space. It can still access files on SCSI 
  6441. disks via the OS/2 Version 2.0 file system. 
  6442.  
  6443. Another example could be a 3270 connection adapter.  Depending on the setup, it 
  6444. could occupy 8KB of memory (for example, X'DE000' to X'E0000'). If you are 
  6445. using Extended Services and Communications Manager to establish a DFT 
  6446. connection to your /370 system, you could release this memory for use by DOS 
  6447. applications and specify this address frame in the Include Region.  Of course, 
  6448. if you want to use a DOS-based emulator, such as Personal Communications/3270 
  6449. Version 2.0, you can't include this area, as the DOS application and its device 
  6450. driver want to access this adapter directly. 
  6451.  
  6452. Note:   The MEM_INCLUDE_REGIONS parameter should be entered as shown above, 
  6453.         using 5-digit hex addresses (not 4-digit segment addresses, as is often 
  6454.         the case). Also, note that the range is inclusive - you must specify 
  6455.         the second address as (for example) X'DFFFF', not X'E0000'. The 
  6456.         parameter is not validity-checked when entered. If an invalid parameter 
  6457.         is saved, the default (no include region) is used when the VDM is 
  6458.         initialized; no error message is generated. 
  6459.  
  6460. In summary, a typical DOS VDM may have a 64KB EMS page frame and 64KB of UMBs 
  6461. (or 128KB of UMBs) regardless of the hardware adapters installed. Such a 
  6462. configuration is not possible under PC DOS. 
  6463.  
  6464.  
  6465. ΓòÉΓòÉΓòÉ 16.3. Extended Memory Support ΓòÉΓòÉΓòÉ
  6466.  
  6467. The OS/2 Version 2.0 Multiple Virtual DOS Machines architecture provides 
  6468. support for the LIMA Extended Memory Specification Version 2.0 specification, 
  6469. in a similar manner to that provided for LIM EMS Version 4.0, using normal 
  6470. system memory and emulating XMS functions.  The following discusses how MVDM 
  6471. support for the extended memory specification has been implemented. 
  6472.  
  6473. The extended memory specification manages three different kinds of memory: 
  6474.  
  6475.  High Memory Area (HMA) 
  6476.  
  6477.  Upper Memory Blocks (UMBs) in the Upper Memory Area (UMA) 
  6478.  
  6479.  Extended Memory Blocks (EMBs). 
  6480.  
  6481. Each of these areas is discussed as they relate to the implementation of 
  6482. expanded memory support for VDMs in OS/2 Version 2.0. Figure "Memory Map of 
  6483. Areas Supported by Extended Memory"below shows where these memory areas or 
  6484. blocks reside in memory. 
  6485.  
  6486. For more information regarding the Expanded Memory Specification, refer to DOS 
  6487. Protected Mode Interface. 
  6488.  
  6489. The OS/2 Version 2.0 LIMA XMS emulation provides the following functions: 
  6490.  
  6491.  Implements all LIMA XMS Version 2.0 functions. 
  6492.  
  6493.  Provides each VDM with a separate XMS emulation.  Each VDM has its own High 
  6494.   Memory Area, Upper Memory Blocks and Extended Memory Blocks; hence features 
  6495.   such as interprocess communication work as if each VDM was running on a 
  6496.   different real 80386.  A VDM therefore cannot affect the availability of 
  6497.   extended memory objects in other VDMs or access memory owned by other VDMs. 
  6498.  
  6499.  Provides configurable limits for how much XMS memory is available across all 
  6500.   VDMs as well as a limit per-VDM.  The DOS Settings feature can override the 
  6501.   per-VDM limit, subject to the constraint given by the overall limit, and can 
  6502.   disable XMS altogether for a particular VDM if its installation conflicts 
  6503.   with the program being run in the VDM. 
  6504.  
  6505.  XMS can be removed and the operating system can run without loading XMS in 
  6506.   any VDM session. 
  6507.  
  6508. Applications which use extended memory may use the XMS support in the same 
  6509. manner as in a native DOS environment.  In addition, portions of the DOS 
  6510. operating system, device drivers and TSR programs may be loaded into extended 
  6511. memory, thereby conserving memory within the DOS application address space for 
  6512. application use. 
  6513.  
  6514. Note that older applications which access extended memory directly, rather than 
  6515. through an extended memory manager, may not be compatible with the XMS support 
  6516. under MVDM.  For example, Microsoft Windows Version 2.x cannot make use of 
  6517. extended memory in a VDM. 
  6518.  
  6519.  
  6520. ΓòÉΓòÉΓòÉ 16.3.1. Extended Memory Manager ΓòÉΓòÉΓòÉ
  6521.  
  6522. XMS services are implemented under MVDM using a virtual device driver known as 
  6523. the Virtual Extended Memory Manager (VXMM) which is represented by the file 
  6524. VXMS.SYS (VXMS). VXMM provides a separate XMS emulation for each VDM by placing 
  6525. most VXMS control structures in a per-VDM data area outside the V86 mode 
  6526. address space. The amount of memory available to a VDM, the number of handles, 
  6527. and the existence of Upper Memory Blocks (UMBs) are all configurable parameters 
  6528. which may be altered on a per-VDM basis. 
  6529.  
  6530. The VXMM hooks interrupt vector 2Fh in order to announce its presence to 
  6531. applications. It also provides a V86 stub device driver (XMM 3X device driver), 
  6532. which indicates to DOS applications that XMS is available, but more importantly 
  6533. acts as a V86 mode interface between the application and the VXMM proper. 
  6534.  
  6535. VXMM depends heavily upon the memory manager.  XMS object allocation 
  6536. reallocation, and deallocation are accomplished by requesting corresponding 
  6537. services from the memory manager.  When an application requests the allocation 
  6538. of a block of extended memory, for example, VXMS asks the memory manager to 
  6539. allocate a memory object in linear memory outside any VDM.  Reallocation and 
  6540. deallocation are handled similarly. 
  6541.  
  6542. All EMS functions are executed by calling the XMS Control Function, the address 
  6543. of which can be obtained by a call to INT 2Fh. Arguments are passed in 
  6544. registers. 
  6545.  
  6546. Figure "Extended Memory Manager Control Flow" 
  6547.  
  6548. During the initialization of the VDM the VDM Manager loads and initializes the 
  6549. XMM DOS stub device driver into the VDM address space. As soon as there is a 
  6550. XMS request the VDM Manager loads the the XMS virtual device driver VXMS. 
  6551.  
  6552.     a) The VDM Application issues a INT 15h service request. VXMS directly 
  6553.        hooks INT 15h for function 87h and 88h. It does not provide any services 
  6554.        through these calls but makes sure that no program tries to use extended 
  6555.        memory directly. INT 15h function 88h will respond that no normal 
  6556.        extended memory is available. Programs that want to use extended memory 
  6557.        directly by using INT 15 and RAMdisks (electronic disks) using INT 15 
  6558.        won't work. The MS DOS RAMDRIVE for DOS 5.0 does work because it uses 
  6559.        XMS instead of INT 15. 
  6560.  
  6561.     b) The VDM application issues INT 2Fh to determine if an XMS driver is 
  6562.        installed. 
  6563.  
  6564.     c) The VDM application issues INT 2Fh to determine if an XMS driver is 
  6565.        installed. 
  6566.  
  6567.     d) Next the VDM application issues a INT 2Fh to obtain the address of the 
  6568.        XMS driver's control function.  As soon as the VDM Application got the 
  6569.        address of the XMS driver's control function it can use any of the 
  6570.        functions and call the XMM DOS stub device driver directly. 
  6571.  
  6572.     e) The VDM application calls the XMS driver's control function to access 
  6573.        all of the XMS functions. 
  6574.  
  6575.     f) The XMM DOS stub device driver calls breakpoint traps by the VXMM 
  6576.        Control Function. 
  6577.  
  6578.     g) The VDM Manager initialization, creation, termination calls for 
  6579.        XMS-Objects. The VDM Manager traps the VDM application's INT 15h service 
  6580.        request and routes it to VXMS as well as XMS control function requests 
  6581.        for XMS memory. 
  6582.  
  6583.     h) The VXMS requests corresponding services from the VDH services: 
  6584.  
  6585.        Creation/termination handler registration 
  6586.  
  6587.        INT 67h prehooking 
  6588.  
  6589.        Linear address reservation 
  6590.  
  6591.        Memory management 
  6592.  
  6593.        Obtaining configuration information. 
  6594.  
  6595.     i) The result is returned. 
  6596.  
  6597. Like VEMM and unlike most other virtual device drivers, VXMS.SYS does not have 
  6598. a corresponding physical device driver.  Instead, it depends heavily upon the 
  6599. OS/2 Version 2.0 memory manager.  XMS object allocation, reallocation and 
  6600. deallocation are accomplished by requesting corresponding services from the 
  6601. operating system's memory manager.  For example, when an application requests 
  6602. the allocation of a block of extended memory, VXMM requests the memory manager 
  6603. to allocate a memory object in linear memory outside the V86 mode address 
  6604. space.  Reallocation and deallocation are handled similarly. 
  6605.  
  6606. Structure 
  6607.  
  6608. The VXMS.SYS module consists of: 
  6609.  
  6610.  1. An initialization component that initializes global structures and reads 
  6611.     the global configuration at boot time. 
  6612.  
  6613.  2. A creation component that initializes per-VDM structures, reads per-VDM 
  6614.     configuration values, and installs the DOS device driver stub when a VDM is 
  6615.     created. 
  6616.  
  6617.  3. A router component that receives control from the control function 
  6618.     contained in the stub device driver, and dispatches the call to an 
  6619.     appropriate service routine.  In addition, the router function hooks 
  6620.     interrupt vector 15h upon the first non-version-query call to VXMM, as 
  6621.     required by the specifications, in order to: 
  6622.  
  6623.     a) Preserve the state of the A20 line across block copies (service AH=87h). 
  6624.  
  6625.     b) Respond to service AH=88h (Query Extended Memory) by reporting that 
  6626.        there is no extended memory available. 
  6627.  
  6628.  4. A number of service routines, which perform the required XMS functions. 
  6629.  
  6630. Applications request XMS services by calling a subroutine contained within the 
  6631. VXMM, known as the Control Function.  The VXMS virtual device driver hooks 
  6632. interrupt vector 2Fh in  order to announce its presence to applications. 
  6633.  
  6634. Initialization 
  6635.  
  6636. VXMS.SYS may be loaded at system initialization time by using a DEVICE= 
  6637. statement in CONFIG.SYS, as shown below: 
  6638.  
  6639. DEVICE=C:\OS2\MDOS\VXMS.SYS 8192, 2048
  6640.  
  6641. This statement should be placed in CONFIG.SYS after the DEVICE= statement for 
  6642. VEMM.SYS, since VXMM queries VEMM to ensure that no conflicts occur in memory 
  6643. allocation. 
  6644.  
  6645. The DEVICE= statement uses parameters to specify the total amount of available 
  6646. XMS memory, and the default limit for each VDM.  In the above example, the 
  6647. overall limit is set to 8MB and the limit for each VDM is set to 2MB. 
  6648.  
  6649. The virtual device driver VXMS.SYS can be configured as follows. 
  6650.  
  6651.        device = {path} vxms.sys {options}
  6652.  
  6653. The options are of the form "/keyword=value": 
  6654.  
  6655. /XMMLIMIT=g,i       Sets the global (system-wide) maximum memory usage of the 
  6656.                     VXMS.SYS driver to g kilobytes, and a per-VDM maximum of i 
  6657.                     kilobytes.  These values should be large enough to 
  6658.                     accommodate an automatic 64KB allocation in each VDM for 
  6659.                     the HMA.  Values are restricted to the range 0..65535 (= 
  6660.                     64Meg). 
  6661.  
  6662.                     The values of g and i are rounded up to the nearest 
  6663.                     multiple of 4. 
  6664.  
  6665.                     Specifying i = 0 suppresses XMS installation in all VDMs 
  6666.                     unless specifically overridden by a VDM-specific 
  6667.                     configuration string.  (See below.) 
  6668.  
  6669.                     Default:  /XMMLIMIT=4096,1024 
  6670.  
  6671. /HMAMIN=d           Sets the minimum request size (in kilobytes) for an HMA 
  6672.                     request to succeed.  Values are restricted to the range 
  6673.                     0..63. 
  6674.  
  6675.                     Default: /HMAMIN=0 
  6676.  
  6677. /NUMHANDLES=n       Sets the number of handles available in each VDM. Each 
  6678.                     handle occupies eight bytes.  Values are restricted to the 
  6679.                     range 0..128. 
  6680.  
  6681.                     Default: / NUMHANDLES=32 
  6682.  
  6683. /UMB                Instructs XMM to create Upper Memory Blocks 
  6684.  
  6685.                     Default:  off 
  6686.  
  6687. /NOUMB              Instructs XMM not to create Upper Memory Blocks 
  6688.  
  6689.                     Default: /NOUMB 
  6690.  
  6691.                     All other keywords are ignored.  Case is ignored. 
  6692.  
  6693. These options affect all VDMs, but can be overridden by a VDM's configuration 
  6694. strings.  The same option names are available to VDMs (without the prefixing 
  6695. slash), except that XMMLIMIT only takes one numeric argument, corresponding to 
  6696. the value i above.  The value g above cannot be changed once XMM is installed. 
  6697.  
  6698. If a value of i=0 was specified on the DEVICE= line, to create a VDM with XMS 
  6699. installed, specify a configuration string "XMMLIMIT" with a non-zero value. 
  6700. Conversely, to have no XMS installed, specify a configuration string "XMMLIMIT" 
  6701. with a value of zero. 
  6702.  
  6703. If UMBs are being used, it is crucial that VXMS.SYS be the last device driver 
  6704. loaded, for VXMS.SYS reserves all available addresses between 640KB and 1Meg 
  6705. for use as UMBs.  Hence, any device drivers which reserve pages in that region 
  6706. (for example, VEMM) will not be able to install. 
  6707.  
  6708. VXMS.SYS will fail to install if some other device driver has already reserved 
  6709. the region from 1MB to 1MB+64KB. 
  6710.  
  6711. The overall limit comprises the only relationship between XMS memory objects in 
  6712. different VDMs, and is imposed to prevent XMS from acquiring all available 
  6713. memory.  The default overall limit is 4MB, and the default limit for each VDM 
  6714. is 1MB.  The default limit for each VDM can be overridden by installing an 
  6715. application on the desktop and choosing to specify the XMS size with the DOS 
  6716. Settings feature (see DOS Settings). 
  6717.  
  6718. Setting the overall limit to zero disables XMS in all VDMs regardless of the 
  6719. per-VDM value.  Setting the default limit for a particular VDM to zero disables 
  6720. XMS in all VDMs unless their start list entries specify a non-zero XMS size. 
  6721. Setting the XMS size to zero for an entry in the start list disables XMS for 
  6722. that application's VDM only.  Novice users need never change the default 
  6723. values. 
  6724.  
  6725. In addition to memory sizes, the number of handles and the presence or absence 
  6726. of Upper Memory Blocks are all configurable parameters which may be altered on 
  6727. a per-VDM basis using the DOS Settings feature. 
  6728.  
  6729. Upon installation, an initialization routine within VXMS.SYS supplies the 
  6730. addresses of the VXMS.SYS VDM-creation and close routines to the Virtual DOS 
  6731. Machine Manager. 
  6732.  
  6733. VDM Creation 
  6734.  
  6735. Upon creation of a VDM, a VDH service is used to get the maximum XMS size for 
  6736. that VDM.  This will return a string if the program's entry on the desktop has 
  6737. an associated VXMS size.  If the per-VDM size is not defined, the default 
  6738. retrieved from CONFIG.SYS at initialization time will be used. If VXMS size is 
  6739. not 0, the following steps are then performed: 
  6740.  
  6741.  1. Upper Memory Blocks (UMBs) are found and reserved. 
  6742.  
  6743.  2. The High Memory Area (HMA) is reserved. 
  6744.  
  6745.  3. The real mode device driver stub is loaded. 
  6746.  
  6747.  4. The handle table and UMB list are initialized. 
  6748.  
  6749. To find an available linear region to use for UMBs, VXMS requests VDH services 
  6750. to locate the largest free address range in the V86 mode address space above 
  6751. 640KB. VXMS reserves all the pages returned until the call fails. 
  6752.  
  6753. VXMS requests the OS/2 Version 2.0 memory manager to allocate the 64KB region 
  6754. immediately above 1MB for use as the High Memory Area.  The way in which this 
  6755. is accomplished depends upon a number of variables; see High Memory Area (HMA) 
  6756. for further details. 
  6757.  
  6758. Waiting until creation time to reserve this memory allows virtual device 
  6759. drivers with actual hardware to claim their addresses first, since VXMS's UMBs 
  6760. can be placed at any available address.  A consequence is that the space is 
  6761. reserved only for the VDM being created; it could be in a different location or 
  6762. be a different size for other VDMs. 
  6763.  
  6764. VXMS then arranges for the loading of a stub device driver in the VDM. This 
  6765. driver serves three purposes: 
  6766.  
  6767.  The device driver header can be read by an application searching for the name 
  6768.   of the real mode VXMS driver.  It responds to all device requests with "done" 
  6769.   without actually doing anything. 
  6770.  
  6771.  The device driver's initialization code attaches VXMS to interrupt vector 
  6772.   2Fh.  Attaching to vector 2Fh must be delayed until after the virtual DOS 
  6773.   environment has completed hooking all of its interrupts. 
  6774.  
  6775.  The device driver contains the VXMS control function; calls to XMS services 
  6776.   are not performed by calling a software interrupt, but rather by calling a 
  6777.   V86 mode far subroutine called the control function. Moreover, XMS 
  6778.   specifications require the control function to have a particular physical 
  6779.   layout.  Hence, the control function is placed in a DOS device driver so that 
  6780.   it may have the layout required by the specifications and can transfer 
  6781.   control to the virtual device driver code (the router function). 
  6782.  
  6783. The stub device driver is used to transfer control to the router function. A 
  6784. DOS application invokes XMS functions by calling the control function as a far 
  6785. procedure, the address of which can be obtained by a different INT 2Fh call. 
  6786. In response to such a request, the INT 2Fh interrupt handler returns the 
  6787. address of the control function in the device driver stub.  The Control 
  6788. Function then calls the protected mode VXMS entry point, and the router obtains 
  6789. control. 
  6790.  
  6791. The interrupt hook cannot be performed by the VXMS creation function, since the 
  6792. virtual DOS environment does not establish its interrupt hooks until after all 
  6793. virtual device driver creation code has completed.  DOS device driver 
  6794. initialization code is called after the interrupt vectors are set; therefore 
  6795. delaying the hooking of vector 2Fh until DOS device driver initialization time 
  6796. succeeds in hooking the vector. 
  6797.  
  6798. Routing 
  6799.  
  6800. The router receives control from the control function within the stub device 
  6801. driver, as described above.  After checking that the XMS service request is 
  6802. valid, the router calls the appropriate protected mode service routine, which 
  6803. in turn requests the OS/2 Version 2.0 memory manager to allocate and manipulate 
  6804. XMS objects. 
  6805.  
  6806. Information calls involve at most a quick search of structures.  The number of 
  6807. kilobytes VXMS reports as available is the minimum of the number of kilobytes 
  6808. the VDM has left before it hits its per-VDM XMS memory usage limit, the number 
  6809. of kilobytes all VDMs have left before hitting the system-wide memory usage 
  6810. limit, and the amount the memory manager estimates is available. 
  6811.  
  6812.  
  6813. ΓòÉΓòÉΓòÉ 16.3.2. High Memory Area (HMA) ΓòÉΓòÉΓòÉ
  6814.  
  6815. VXMS requests that the operating system's memory manager reserve the region of 
  6816. memory between 1MB and 1MB + 64KB, so that it may use that region for 
  6817. simulating the A20 address line wraparound.  This region of memory is called 
  6818. the High Memory Area (HMA). 
  6819.  
  6820. When the processor's A20 address line is disabled, the HMA is mapped to the 
  6821. first 64KB of conventional memory.  When the A20 address line is enabled, the 
  6822. mapping depends on whether the HMA is in use.  If the A20 address is not 
  6823. enabled, the HMA is mapped to black hole memory.  Black hole memory can safely 
  6824. be accessed by a VDM, but values written to it cannot be retrieved (ROM or 
  6825. invalid physical addresses, for example).  If the HMA is in use, VXMS requests 
  6826. the memory manager to alias a linear region inside the HMA to a memory object 
  6827. outside the V86 mode address space, which has been specially allocated for this 
  6828. purpose. 
  6829.  
  6830. DOS Emulation code may reside in the HMA; this is specified by including the 
  6831. following statement in CONFIG.SYS: 
  6832.  
  6833. DOS=HIGH
  6834.  
  6835. OS/2 Version 2.0 installation places this statement into CONFIG.SYS as a 
  6836. default, and the operating system is thus installed such that DOS Emulation 
  6837. runs in the HMA. The only drawback to using the HMA for DOS Emulation code is 
  6838. that applications are prevented from using the HMA.  This is not usually a 
  6839. serious problem, since few programs require use of the HMA.  It is recommended 
  6840. that DOS Emulation code is loaded in the HMA as this will free base memory for 
  6841. application use. 
  6842.  
  6843. Note that if XMS size is less than 64KB for a VDM, the HMA is not emulated. 
  6844. All requests for the HMA will fail. 
  6845.  
  6846.  
  6847. ΓòÉΓòÉΓòÉ 16.3.3. Upper Memory Blocks (UMBs) ΓòÉΓòÉΓòÉ
  6848.  
  6849. VXMS attempts to reserve all unreserved pages in the region of memory between 
  6850. 640KB and 1MB; this region is often termed the Upper Memory Area (UMA).  The 
  6851. address ranges reserved in this manner will be used to simulate Upper Memory 
  6852. Blocks (UMBs).  Note that this allocation scheme requires that VXMS be the last 
  6853. device driver loaded; any device drivers loaded after VXMS will not be able to 
  6854. reserve any addresses in the UMA. 
  6855.  
  6856. When a UMB is not in use, its corresponding range of addresses is mapped to a 
  6857. black hole.  When it is in use, the range of addresses corresponding to the UMB 
  6858. being allocated is mapped to a memory object outside the V86 mode address space 
  6859. which is allocated for this purpose.  This is similar to the technique used to 
  6860. map objects in the HMA. 
  6861.  
  6862. VXMS uses a delayed UMB allocation scheme.  Unlike conventional XMS 
  6863. implementations, no UMBs are allocated until the first UMB request.  Upon 
  6864. receiving the first UMB request, VXMS queries the UMB region to determine which 
  6865. address ranges are available, and reserves those ranges.  This technique 
  6866. supports memory mapped devices which lie in the same region from which UMBs are 
  6867. taken.  Advanced users can use Include/Exclude Regions in the DOS Settings 
  6868. feature to tell VXMS which ranges are not to be used. 
  6869.  
  6870. Note that by default, all UMBs are owned by the DOS Emulation kernel and are 
  6871. not available for application use.  If an application wishes to use UMBs, the 
  6872. DOS = NOUMB statement must be included in CONFIG.SYS or the application can't 
  6873. get any UMB because they are already used by DOS. Alternatively, the ownership 
  6874. of UMBs for a single VDM may be enabled or disabled using the DOS owns UMBs 
  6875. setting; see DOS Settings. 
  6876.  
  6877. VXMS allows coexistence with EMS services, in that it queries VEMM before 
  6878. reserving address ranges, so that VEMM may reserve the space it requires for 
  6879. its frame.  As such, it is possible that an application using both EMS and XMS 
  6880. services will execute and function correctly. 
  6881.  
  6882. DOS Device Drivers 
  6883.  
  6884. DOS device drivers may be loaded into UMBs, thereby conserving memory within 
  6885. the 640KB DOS application space; this support is functionally compatible with 
  6886. that provided by DOS 5.0.  Loading a DOS device driver into a UMB requires a 
  6887. number of additional statements in CONFIG.SYS; an example is given in Figure 
  6888. "CONFIG.SYS - Loading Device Drivers into UMBs". 
  6889.  
  6890. The first statement causes the VXMS virtual device driver VXMS.SYS to be loaded 
  6891. at initialization time.  The second statement causes the ANSI.SYS device driver 
  6892. to be loaded into a UMB.  The SIZE parameter ensures that the device driver is 
  6893. loaded into a UMB of the required size for its operation;  if a UMB of this 
  6894. size cannot be allocated, the device driver is automatically loaded into low 
  6895. memory. 
  6896.  
  6897. For DOS device drivers loaded into a specific VDM using DOS Device Drivers in 
  6898. the DOS Settings feature, the SIZE parameter is also supported. Specifying a 
  6899. SIZE parameter in DOS Settings will cause the device driver to be loaded into a 
  6900. UMB if possible; if UMBs are not present or if a sufficiently large UMB cannot 
  6901. be allocated, the device driver will be loaded into low memory. 
  6902.  
  6903. Note that device drivers are always loaded into the largest available UMB; 
  6904. hence, in order to achieve efficiency in the utilization of UMBs, device 
  6905. drivers should be loaded in order of size, from largest to smallest.  This is 
  6906. achieved by placing the DEVICE= statements in CONFIG.SYS, or names of the 
  6907. device drivers in the DOS Device Drivers setting, in that order. 
  6908.  
  6909. The third statement allocates ownership of UMBs to the DOS kernel, and prevents 
  6910. applications from accessing UMBs.  This statement sets the default for all 
  6911. VDMs; if an application running in a VDM requires UMBs, the default may be 
  6912. overridden for that VDM using the appropriate DOS Settings function. 
  6913.  
  6914. Note that some device drivers may not function correctly in a UMB if they rely 
  6915. on having all memory above them available for their use.  If incorrect 
  6916. operation of a device driver is experienced in a UMB, the value of the SIZE 
  6917. parameter should be increased by modifying the DEVICEHIGH statement in 
  6918. CONFIG.SYS or by altering the appropriate DOS settings for the VDM. 
  6919.  
  6920. TSR Programs 
  6921.  
  6922. TSR programs may also be loaded into UMBs in order to conserve DOS application 
  6923. space.  TSR programs such as APPEND, which are loaded by default when a VDM is 
  6924. started, are loaded into a UMB where possible, thereby saving approximately 6KB 
  6925. of memory.  Loading a TSR program into a UMB is performed from the DOS command 
  6926. line or from a batch file using the LOADHIGH command, as shown in Figure 
  6927. "LOADHIGH Command - Loading TSRs into UMBs". 
  6928.  
  6929. Note that parameters for TSR programs are supported by the LOADHIGH command. 
  6930.  
  6931. TSR programs which rely on having all memory above their location available for 
  6932. their use may not execute correctly when loaded in a UMB.  In such cases, the 
  6933. TSR must be loaded into low memory. 
  6934.  
  6935.  
  6936. ΓòÉΓòÉΓòÉ 16.3.4. Extended Memory Blocks (EMBs) ΓòÉΓòÉΓòÉ
  6937.  
  6938. Extended Memory Blocks (EMBs) reside in the region above 1MB, and are therefore 
  6939. not directly accessible from DOS applications running in V86 mode.  The only 
  6940. way a DOS application can access EMBs is by using the VXMS service Move 
  6941. Extended Memory Block. VXMS then requests the memory manager to remap the EMB 
  6942. into low memory, from which it may then be accessed by the application.  Each 
  6943. Extended Memory Block is allocated as a separate memory object with linear 
  6944. addresses outside the V86 mode address space. 
  6945.  
  6946. Note that memory requests for UMBs and EMBs are made by applications in units 
  6947. of paragraphs and kilobytes, whereas the memory manager allocates in 4KB pages. 
  6948. VXMS rounds all allocation requests up to the nearest integral page multiple 
  6949. before passing the request on to the operating system's memory manager. 
  6950.  
  6951.  
  6952. ΓòÉΓòÉΓòÉ 16.3.5. Allocating/Deallocating Memory ΓòÉΓòÉΓòÉ
  6953.  
  6954. Application requests to allocate, reallocate, or deallocate Extended Memory 
  6955. Blocks are translated into corresponding call to the memory manager.  A free 
  6956. handle table entry, indicated by a start address of zero, is selected and 
  6957. updated to contain the start address and size of the memory object. The total 
  6958. XMS memory size for the system and for each VDM is checked at this point to 
  6959. ensure that these limits are not exceeded. 
  6960.  
  6961. Reallocation requests are serviced by passing the request to a VDH service and 
  6962. recording the new size and start address.  When an application reallocates to 
  6963. zero, VXMS requests the memory manager to deallocate the memory object, and 
  6964. changes the handle table entry so it has zero pages with a sentinel non-zero 
  6965. address to indicate the handle is still in use. Objects of size zero are 
  6966. allowed in VXMS, but not in OS/2, so VXMS will deallocate but retain its own 
  6967. data for the handle.  When a non-zero reallocation is performed on an object of 
  6968. size zero, a new object is transparently allocated by the memory manager. 
  6969.  
  6970. All allocations (and reallocations) are rounded up to the nearest integral page 
  6971. multiple.  Since there is no facility for telling the applications how much 
  6972. memory was actually reserved, the extra memory is wasted. 
  6973.  
  6974. High Memory Area 
  6975.  
  6976. There is only one HMA per VDM, so a single pointer suffices to manage the state 
  6977. of the HMA. If the pointer is zero, then the HMA is not in use.  Otherwise, the 
  6978. pointer contains the linear address of the block of memory being used to 
  6979. simulate the HMA. Whether the HMA region is mapped to this block of memory is 
  6980. determined by the state of the simulated A20 line; see section High Memory Area 
  6981. (HMA). 
  6982.  
  6983. When a request for the HMA is made, the pointer is tested against zero.  If the 
  6984. pointer is non-zero, then the HMA is in use, and the request fails. Otherwise, 
  6985. the pointer is set to a newly allocated 64KB block of memory, and the HMA 
  6986. region is mapped to this block if the A20 address line is active. 
  6987.  
  6988. When the HMA is released, the block of memory is freed, and the pointer is 
  6989. reset to 0.  The HMA is then mapped to a black hole if the A20 address line is 
  6990. active.  Once an HMA is freed, all information previously stored therein 
  6991. becomes invalid. 
  6992.  
  6993. Upper Memory Blocks 
  6994.  
  6995. For UMB allocation, a linked list of reserved address ranges is maintained. 
  6996. This list contains information about the start address of each reserved range, 
  6997. the base address of the physical memory block allocated and mapped into address 
  6998. range, and the length of the block. If the base address is zero, then the 
  6999. address range is not in use and is instead mapped to a black hole. 
  7000.  
  7001. Allocations are made by searching through the list to find an address range for 
  7002. which the base address is zero and which is large enough to satisfy the 
  7003. request.  If the address range exceeds the required size, it is split into two 
  7004. parts and a new object is allocated to hold the unused portion. 
  7005.  
  7006. Deallocations are made by searching the list to find a structure whose starting 
  7007. address matches the one being deallocated.  The physical memory into which the 
  7008. address range was mapped is freed, and the address range is instead remapped to 
  7009. a black hole.  Finally, the newly freed object has its base address set to zero 
  7010. to signify that it is not in use.  It is then coalesced with any adjacent free 
  7011. blocks. 
  7012.  
  7013. Extended Memory Blocks 
  7014.  
  7015. Each VDM has a fixed table of up to 255 EMB handles, the exact number of which 
  7016. is under user control.  Each entry of the table describes a single Extended 
  7017. Memory Block. 
  7018.  
  7019. Each entry contains a field which records the number of active locks on the 
  7020. Extended Memory Block.  Locking a handle prevents the corresponding Extended 
  7021. Memory Block form being reallocated or freed, and also prevents the base 
  7022. address from changing.  As part of its function, the lock subfunction returns 
  7023. the 32-bit base address. 
  7024.  
  7025. If an allocation is of size zero, no physical memory allocation is requested, 
  7026. but a sentinel non-zero address and zero size are recorded in the handle entry. 
  7027. The lock count for the newly created Extended Memory Block is reset to zero. 
  7028.  
  7029. When a deallocation request is made for an Extended Memory Block with zero lock 
  7030. count, the address in the handle is changed to zero, and the memory manager is 
  7031. called to free the memory. 
  7032.  
  7033.  
  7034. ΓòÉΓòÉΓòÉ 16.4. Problems with Extended Memory ΓòÉΓòÉΓòÉ
  7035.  
  7036. If an application in a VDM encounters an error due to insufficient extended 
  7037. memory, the following points should be checked: 
  7038.  
  7039.  Ensure the overall limit and the limit for the VDM are large enough to 
  7040.   accommodate the amount of extended memory required by the application. 
  7041.  
  7042.  Ensure that the DEVICE= statement for VMXS.SYS is in CONFIG.SYS. 
  7043.  
  7044.  Ensure that the expanded memory driver VEMM.SYS, is not using all of the 
  7045.   available memory.  The amount of memory allocated to VEMM may be reduced by 
  7046.   changing the parameters of the DEVICE= statement for VEMM to something less 
  7047.   than that specified (or less than the default which is 4MB).  If necessary, 
  7048.   VEMM command may be disabled by removing or remarking out the DEVICE= 
  7049.   statement in CONFIG.SYS. 
  7050.  
  7051.  Ensure that CONFIG.SYS and/or AUTOEXEC.BAT do not start unnecessary programs 
  7052.   that use extended memory. 
  7053.  
  7054. If a program does not start and displays a message such as High Memory Area 
  7055. (HMA) already in use, the HMA may be freed by disabling the DOS=HIGH statement 
  7056. in CONFIG.SYS.  If the statement is DOS=HIGH, UMB then the statement should be 
  7057. changed to DOS=UMB. 
  7058.  
  7059.  
  7060. ΓòÉΓòÉΓòÉ 16.5. Summary ΓòÉΓòÉΓòÉ
  7061.  
  7062. MVDM provides support for applications which use the LIM EMS Version 4.0 and 
  7063. LIMA XMS Version 2.0 memory extenders to access more than 640KB of memory.  The 
  7064. memory requested is allocated from OS/2 Version 2.0 system memory, and is 
  7065. managed by the operating system kernel; special hardware is not required. Each 
  7066. VDM has its own copy of EMS or XMS memory objects, and the objects of one VDM 
  7067. are protected from access by another VDM. 
  7068.  
  7069. Support for these memory extenders is provided by two virtual device drivers, 
  7070. VEMM.SYS and VXMS.SYS.  Unlike most virtual device drivers, these drivers do 
  7071. not have corresponding physical device drivers, but access the operating 
  7072. system's memory manager to handle memory allocation requests from applications. 
  7073.  
  7074. MVDM supports the loading of DOS device drivers and TSR programs into XMS Upper 
  7075. Memory Blocks, in order to reduce memory consumption below the 640KB line, 
  7076. thereby leaving more base memory for applications.  Loading of these programs 
  7077. into UMBs is supported by the DEVICEHIGH statement in CONFIG.SYS and the 
  7078. LOADHIGH command included in AUTOEXEC.BAT or executed from the command line. 
  7079.  
  7080.  
  7081. ΓòÉΓòÉΓòÉ 17. Installing and Migrating Applications ΓòÉΓòÉΓòÉ
  7082.  
  7083. Installing DOS and Windows applications under OS/2 V2.0 is in most cases very 
  7084. similar to installing them in their native environments. However, since OS/2 
  7085. V2.0 is a true multitasking operating system, we should ensure that the 
  7086. installation programs do not introduce incompatibilities with existing 
  7087. programs. The flexibility in tailoring the virtual DOS machine environment for 
  7088. these programs, also gives us an opportunity to easily tune DOS settings to 
  7089. suit our needs. 
  7090.  
  7091. OS/2 V2.0 has a utility to help users place their application icons onto the 
  7092. desktop after they have been installed. The utility uses information stored in 
  7093. a migration database that is shipped with OS/2 V2.0. 
  7094.  
  7095. Systems administrators can use another utility to create their own migration 
  7096. database to install their corporation's unique applications. 
  7097.  
  7098. This chapter discusses the installation of DOS and Windows applications under 
  7099. OS/2 V2.0. It also shows how to use the application migration utilities shipped 
  7100. with OS/2 V2.0. 
  7101.  
  7102. We describe the use of the migration program in this chapter, and show an 
  7103. example of how to use the PARSEDB utility to create a customized migration 
  7104. database. 
  7105.  
  7106.  
  7107. ΓòÉΓòÉΓòÉ 17.1. Installing DOS Programs ΓòÉΓòÉΓòÉ
  7108.  
  7109. Application installation methods vary widely in the DOS world. Some 
  7110. installations involve nothing more than copying the software from diskette to 
  7111. the hard disk. In more complex applications, the install procedure may check 
  7112. the workstation configuration (both hardware and software), implement copy 
  7113. protection and modify system files. 
  7114.  
  7115. For most DOS applications, installation under OS/2 Version 2.0 is simply a 
  7116. matter of starting a DOS full-screen or windowed session and following the 
  7117. instructions supplied with the package as if the installation was taking place 
  7118. on a DOS system. However, some may not work correctly because of the special 
  7119. requirements of the installation program. 
  7120.  
  7121.  
  7122. ΓòÉΓòÉΓòÉ 17.1.1. General Installation Procedure for DOS Programs ΓòÉΓòÉΓòÉ
  7123.  
  7124. To install a new DOS program: 
  7125.  
  7126.  1. Read the installation instructions for the DOS program. 
  7127.  
  7128.  2. Select the OS/2 System icon. 
  7129.  
  7130.  3. Select the Command Prompts icon. 
  7131.  
  7132.  4. Select the DOS Full Screen icon. 
  7133.  
  7134.  5. Type the installation command as specified in the installation instructions 
  7135.     on the command prompt. 
  7136.  
  7137.     For example: 
  7138.  
  7139.         a:install
  7140.  
  7141.  6. Follow the instructions on the screen. 
  7142.  
  7143.  7. When installation is complete, close the Command Prompts folder. 
  7144.  
  7145. To add an icon to the desktop, you can use either: 
  7146.  
  7147.  The Program template in the Templates folder (refer to Running DOS 
  7148.   Applications.) 
  7149.  The Migrate Applications program (refer to Migrating Programs.). 
  7150.  
  7151.  
  7152. ΓòÉΓòÉΓòÉ 17.1.2. Installation Programs with Special Requirements ΓòÉΓòÉΓòÉ
  7153.  
  7154. Some DOS application installation programs will not run properly in the OS/2 
  7155. V2.0 virtual DOS machine, or will not install the program correctly. Some of 
  7156. the possible problems are as follows: 
  7157.  
  7158.  1. The installation program attempts to verify the version of DOS that is 
  7159.     running, and receives a response that it cannot understand. One example is 
  7160.     Lotus 1-2-3 Release 3.1+. 
  7161.  
  7162.     The OS/2 V2.0 virtual DOS machine environment can be customized to return a 
  7163.     DOS version in response to the installation program query and thus bypass 
  7164.     the problem. This is accomplished by changing the DOS_Version  parameters 
  7165.     in the DOS Settings facility, which is accessed by pressing the DOS 
  7166.     Settings push button on the Session page of the Settings notebook. 
  7167.  
  7168.     The DOS Settings facility and the available settings are described in 
  7169.     detail in DOS Settings. 
  7170.  
  7171.  2. The copy protection or user registration scheme implemented by the 
  7172.     application bypasses DOS and directly accesses the disk. The OS/2 V2.0 
  7173.     system will not allow the installation program to do this, since it may 
  7174.     interfere with other applications, and will terminate the virtual DOS 
  7175.     machine in which it is running. 
  7176.  
  7177. It may therefore be necessary to perform the installation in a native DOS 
  7178. environment by rebooting the workstation with a DOS boot diskette. When the 
  7179. installation is complete, the workstation can be rebooted under OS/2 V2.0 and 
  7180. the application added to the Workplace Shell. 
  7181.  
  7182.  
  7183. ΓòÉΓòÉΓòÉ 17.2. Planning Hard Disk Partitions ΓòÉΓòÉΓòÉ
  7184.  
  7185. If the workstation is booted from a DOS diskette in order to perform the DOS 
  7186. application install, the installation is restricted to those logical drives 
  7187. that have been formatted as FAT. This is because logical HPFS drives cannot be 
  7188. accessed in a native DOS environment. 
  7189.  
  7190. When the system is booted with DOS 5, HPFS drives are not assigned drive 
  7191. letters and are invisible to the user. If DOS 4.01 with CSD UR35284 is used to 
  7192. perform the boot, drive letters will be assigned to all drives, whether HPFS or 
  7193. FAT. However, you cannot access the files on the HPFS drives. With earlier 
  7194. versions of DOS, even FAT drives that lie beyond the first HPFS drive will not 
  7195. be assigned drive letters. 
  7196.  
  7197. Some installation programs store directory information into control files that 
  7198. are used at run time. For example, WordPerfect** 5.1 records the path to its 
  7199. subdirectories. On a hard disk with both FAT and HPFS logical drives, this can 
  7200. cause the installation program run in native DOS to record drive assignments 
  7201. that are wrong when the application is started from a virtual DOS machine. 
  7202.  
  7203. Consider the following example of a hard disk setup for dual boot or with Boot 
  7204. Manager: 
  7205.  
  7206. Table "Drive Letter Assignment" 
  7207.  
  7208. Note that FAT drive in the extended partition appears as drive E: to the OS/2 
  7209. Version 2.0 virtual DOS machine, but appears as drive D: when booted under DOS. 
  7210. Consequently, if the DOS application is installed on that partition when the 
  7211. system was booted under DOS, the drive letter it records in its control files 
  7212. will be D:. When the system is rebooted under OS/2 V2.0 and the application is 
  7213. run from a virtual DOS machine, the application will be looking to drive D:, 
  7214. which under OS/2 V2.0 is assigned to the HPFS drive of the extended partition. 
  7215. This will cause the application to miss the information it is seeking. 
  7216.  
  7217. The user may be able to change the control file information and correct the 
  7218. error through the application. However, if the system is booted from DOS and 
  7219. the application is started, it will again be looking for the wrong drive. 
  7220.  
  7221. In order to avoid this confusion we recommend that HPFS logical drives be 
  7222. placed last. In the above example, the FAT and HPFS logical drives in the 
  7223. extended partition should be transposed. This will allow the drive letters for 
  7224. the FAT partitions to be the same regardless of whether the workstation is 
  7225. booted from DOS or OS/2 Version 2.0. 
  7226.  
  7227. More details on hard disk management can be found in Chapter 4 of the OS/2 2.0 
  7228. Installation Guide. 
  7229.  
  7230.  
  7231. ΓòÉΓòÉΓòÉ 17.3. Installing Windows Programs ΓòÉΓòÉΓòÉ
  7232.  
  7233. Windows programs installation are usually performed from the DOS command 
  7234. prompt, or the Windows Program Manager. 
  7235.  
  7236. To install a new Windows program: 
  7237.  
  7238.  1. Read the the program installation instructions. 
  7239.  
  7240.  2. To install the program from a DOS command prompt: 
  7241.  
  7242.     a) Select the OS/2 System icon. 
  7243.  
  7244.     b) Select the Command Prompts folder. 
  7245.  
  7246.     c) Select DOS Full Screen. 
  7247.  
  7248.     d) Enter the installation command as specified in the installation 
  7249.        instructions. 
  7250.  
  7251.        For example: 
  7252.  
  7253.               a:setup
  7254.  
  7255.     e) Follow the instructions on the screen to complete the installation. 
  7256.  
  7257.  3. To install the program from the Program Manager: 
  7258.  
  7259.     a) Select the OS/2 System icon. 
  7260.  
  7261.     b) Select the Command Prompts folder. 
  7262.  
  7263.     c) Select WIN-OS/2 Full Screen. 
  7264.  
  7265.     d) Select Run from the File pull-down on the action bar. 
  7266.  
  7267.     e) Enter the installation command as specified in the installation 
  7268.        instructions. 
  7269.  
  7270.        For example: 
  7271.  
  7272.               a:setup
  7273.  
  7274.     f) Follow the instructions on the screen to complete the installation. 
  7275.  
  7276. To add an icon to the desktop, you can use either: 
  7277.  
  7278.  The Program template in the Templates folder (refer to Running DOS 
  7279.   Applications.) 
  7280.  The Migrate Applications program (refer to Migrating Programs.). 
  7281.  
  7282. If you use the Migrate Applications option, the program icon will be placed in 
  7283. the Windows Programs folder or the Additional Windows Programs folder on the 
  7284. desktop. 
  7285.  
  7286. The Migrate Applications program always sets up Windows programs to run in a 
  7287. WIN-OS/2 window session if possible. WIN-OS/2 window sessions cannot be used 
  7288. for programs that have to be run in real mode, such as Windows 2.0 programs. 
  7289. Therefore if you use the Migrate Applications utility on Windows 2.0 programs, 
  7290. open the Settings Notebook to the Sessions page and select the WIN-OS/2 full 
  7291. screen radio button. 
  7292.  
  7293.  
  7294. ΓòÉΓòÉΓòÉ 17.4. AUTOEXEC.BAT and CONFIG.SYS ΓòÉΓòÉΓòÉ
  7295.  
  7296. The installation program for a DOS or Windows application may alter the 
  7297. AUTOEXEC.BAT (usually to modify the PATH statement) and CONFIG.SYS (to modify 
  7298. the FILES and BUFFERS statements or add a DEVICE statement). Usually the copies 
  7299. edited are the ones found in the root directory of the OS/2 V2.0 boot drive. If 
  7300. the option is given the user should not allow the installation program to make 
  7301. the modifications before reviewing the changes. We recommend that you back up 
  7302. both of these files prior to running an installation. After installation, 
  7303. inspect the date and time stamps of the files to see if they have been 
  7304. modified. 
  7305.  
  7306. The most common change made to the AUTOEXEC.BAT file is to the PATH statement, 
  7307. so that the program being installed can be started from any subdirectory. The 
  7308. function of the PATH statement can be provided in a virtual DOS machine by 
  7309. using the Path and file name and Working directory fields of the Program page 
  7310. of the Settings notebook. 
  7311.  
  7312. Since the CONFIG.SYS is used for every virtual DOS machine, the device driver 
  7313. that an installation program adds will be loaded for all VDMs and consume 
  7314. system resources unnecessarily. We recommend that when the DOS application is 
  7315. added to the Workplace Shell the device driver statement be added via the 
  7316. DOS_DEVICE  setting  in the DOS Settings facility. This setting is accessed by 
  7317. pressing the DOS Settings push button on the Session  page of the Settings 
  7318. notebook. 
  7319.  
  7320.  
  7321. ΓòÉΓòÉΓòÉ 17.5. Migrating Programs ΓòÉΓòÉΓòÉ
  7322.  
  7323. OS/2 V2.0 provides a migration database (DATABASE.DAT) that contains parameters 
  7324. and settings for commonly used DOS, Windows and OS/2 programs. This binary 
  7325. database file is used by the Migrate Applications program to place the program 
  7326. icons onto the desktop and customize their Settings notebooks to the 
  7327. recommended values. 
  7328.  
  7329. Figure "The Migrate Applications Windows" 
  7330.  
  7331. To use the Migrate Applications program, follow these steps: 
  7332.  
  7333.  1. Locate and select the OS/2 System icon on the desktop. 
  7334.  
  7335.  2. Select System Setup. 
  7336.  
  7337.  3. Select Migrate Applications. 
  7338.  
  7339.     The Find Programs window appears. The Database Used for Find Option field 
  7340.     displays the default database (\OS2\INSTALL\DATABASE.DAT). The Migrate 
  7341.     Applications program compares programs on the hard disk with the list of 
  7342.     programs in the database and places any that match in a DOS, OS/2, or 
  7343.     Windows programs folder on the desktop. 
  7344.  
  7345.  4. From the Drives list, deselect the drives which should not be searched. The 
  7346.     default is to search all drives. 
  7347.  
  7348.  5. Deselect the types of programs that should not be migrated in the Migrate 
  7349.     type check boxes. The default is to migrate all the listed programs. 
  7350.  
  7351.  6. Select Find.... The Migrate Programs window appears. Programs are listed in 
  7352.     the Applications list box. 
  7353.  
  7354.  7. If your program is not on the list: 
  7355.  
  7356.     a) Select the Add Programs... push button. The Add Programs window appears. 
  7357.        Programs are listed in the Available Programs list. 
  7358.  
  7359.     b) Highlight a program. The Working directory and Program title fields are 
  7360.        filled in. Type a new title if required. 
  7361.  
  7362.     c) Type the appropriate parameters for the selected program in the 
  7363.        Parameters field. 
  7364.  
  7365.     d) Select the types of programs to migrate in the Program type field. The 
  7366.        Migrate Applications program creates the Additional Programs folders 
  7367.        based on the types of programs specified. 
  7368.  
  7369.     e) Select Add. The program moves to the Selected Programs list. 
  7370.  
  7371.     f) Select OK. The Migrate Programs window appears. 
  7372.  
  7373.  8. Select Migrate to migrate all the selected programs. When migration is 
  7374.     complete, the Find Programs window reappears. 
  7375.  
  7376.  9. Select Exit. 
  7377.  
  7378. The Migrate Applications program creates a DOS Programs folder and a Windows 
  7379. Programs folder. The programs in these folders have the recommended 
  7380. pre-selected settings that work best for your programs' performance. 
  7381.  
  7382. If the Add Programs option was used, an Additional DOS Programs folder and an 
  7383. Additional Windows Programs folder will also be created. The programs in these 
  7384. folders have default  settings. If these programs do not run correctly, specify 
  7385. other settings. See DOS Settings on the use of the settings. 
  7386.  
  7387.  
  7388. ΓòÉΓòÉΓòÉ 17.6. Creating a Customized Migration Database ΓòÉΓòÉΓòÉ
  7389.  
  7390. Some corporate users have an installed base of unique or custom-written DOS and 
  7391. Windows applications. These programs will not be listed in the migration 
  7392. database (DATABASE.DAT) that is supplied with OS/2 V2.0. The PARSEDB.EXE 
  7393. program is provided by OS/2 V2.0 to allow a system administrator to build a 
  7394. customized migration database that can be used to set up these unique 
  7395. applications on the Workplace Shell desktop. 
  7396.  
  7397.  
  7398. ΓòÉΓòÉΓòÉ 17.6.1. PARSEDB ΓòÉΓòÉΓòÉ
  7399.  
  7400. A customized migration database is created as follows: 
  7401.  
  7402.  1. Create the input text_database file 
  7403.  
  7404.  2. Run PARSEDB to create the binary database file. 
  7405.  
  7406. To start PARSEDB, type the following statement from a command prompt: 
  7407.  
  7408.  PARSEDB [path] DBTAGS.DAT [path] text_database [path] binary_database
  7409.  
  7410. where: 
  7411.  
  7412.  DBTAGS.DAT is the file name that contains the definitions for the tags used 
  7413.   to define the DOS settings 
  7414.  text_database is the name of the file that contains the program settings for 
  7415.   a specific DOS, OS/2 or Windows program 
  7416.  binary_database is the name of the new migration database file. 
  7417.  
  7418. The text_database file is the main input file for PARSEDB that has to be 
  7419. created. 
  7420.  
  7421. For example, type the following statement to create a  new database named 
  7422. MYDATA.DAT: 
  7423.  
  7424. PARSEDB E:\OS2\INSTALL\DBTAGS.DAT MYDATA.TXT MYDATA.DAT
  7425.  
  7426. Note that you must specify a file name for the binary database file to prevent 
  7427. the PARSEDB utility program from overwriting the default database file 
  7428. DATABASE.DAT. 
  7429.  
  7430. When creating the text_database file, each program must have the following 
  7431. migration information: 
  7432.  
  7433. NAME      Name of the file that runs the program. 
  7434.  
  7435. TITLE     Program object name that appears below the icon. 
  7436.  
  7437. TYPE      DOS, Windows or OS/2 
  7438.  
  7439. ASSOC_FILE File name associated with the file name specified in the Name field. 
  7440.           Use this file name to uniquely identify the program. 
  7441.  
  7442. DEF_DIR   Directory that the program is installed into. 
  7443.  
  7444. ASSOC_FILE and DEF_DIR can have NULL values; NULL values must be included when 
  7445. defining the program if specific values for these fields cannot be provided. 
  7446.  
  7447. When creating MYDATA.TXT, group the settings for a given program on consecutive 
  7448. lines. Use blank lines to mark the end of a program's settings. Begin non-blank 
  7449. lines with a token. The tag file DBTAGS.DAT defines valid token settings, 
  7450. limits, and default values for various DOS properties. 
  7451.  
  7452. Here is the listing of DBTAGS.DAT: DBTAGS.DAT 
  7453.  
  7454. The layout of each line in DBTAGS.DAT is as follows: 
  7455.  
  7456. INDEX VALUE TYPE (optional comments)
  7457.  
  7458. where: 
  7459.  
  7460. INDEX     Is a sequence number 
  7461.  
  7462. VALUE     Is the name of the setting 
  7463.  
  7464. TYPE      Is the type of the value. 
  7465.  
  7466. TYPE is one of the following: 
  7467.  
  7468. NOP       Comments; any line with this type is ignored 
  7469.  
  7470. STR       A string value 
  7471.  
  7472. INT       An integer value 
  7473.  
  7474. BOOL      Boolean, with value of ON or OFF 
  7475.  
  7476. BYTE      Program type, either DOS, OS/2, or Windows. 
  7477.  
  7478. MLSTR     A multi-line string with component lines on individual lines in the 
  7479.           text_database file. 
  7480.  
  7481. Using these types, various settings for programs can be defined. Do not edit 
  7482. DBTAGS.DAT or create a new one; the tag file is available only as a reference 
  7483. when creating the MYDATA.TXT file. 
  7484.  
  7485. PARSEDB checks the validity of all entries in MYDATA.TXT and compares them to 
  7486. the  settings definitions in DBTAGS.DAT. If all entries are valid, PARSEDB 
  7487. creates a binary database named MYDATA.DAT. 
  7488.  
  7489. Errors in the text file will cause PARSEDB to exit and display a message: 
  7490.  
  7491.  A message that a file is corrupted indicates embedded ASCII NUL characters in 
  7492.   the input text file. 
  7493.  A message about an invalid setting indicates the use of a setting not found 
  7494.   in DBTAGS.DAT. The message should include a line number and the name of the 
  7495.   input file. 
  7496.  A message that an entry has missing parameters indicates the absence of the 
  7497.   minimum settings for the entry. 
  7498.  
  7499. PARSEDB does not check for duplicate entries in the input text file, nor does 
  7500. it require settings to be in any particular order. It is also not case 
  7501. sensitive, that is, "Off" is treated the same as "OFF". 
  7502.  
  7503. We recommend that a copy of the input text file (DATABASE.TXT) for the default 
  7504. migration database file (DATABASE.DAT) be made and used as the template for 
  7505. your own input file. A sample input text file is listed below. 
  7506.  
  7507. User Definitions for other Applications 
  7508.  
  7509.  
  7510. ΓòÉΓòÉΓòÉ 17.7. Summary ΓòÉΓòÉΓòÉ
  7511.  
  7512. DOS and Windows application installation under OS/2 V2.0 is generally performed 
  7513. from a DOS command prompt or from the WIN-OS/2 Program Manager. In some cases, 
  7514. it may be necessary to boot from a DOS diskette to perform the install. 
  7515. Modifications made to CONFIG.SYS and AUTOEXEC.BAT by installation programs 
  7516. should be carefully reviewed. 
  7517.  
  7518. If the OS/2 V2.0 system is to be set up for Boot Manager or dual boot to DOS, 
  7519. the arrangement of the hard disk partitions needs to be planned. 
  7520.  
  7521. The Migrate Applications program is used to migrate already installed DOS, 
  7522. Windows, and OS/2 programs, and creates and places the program objects in a 
  7523. folder on the desktop. If the DOS or Windows program is in the migrate database 
  7524. \OS2\INSTALL\DATABASE.DAT, the Migrate Applications program automatically 
  7525. selects the recommended DOS settings for the program. 
  7526.  
  7527. The Migrate Applications program always sets up Windows programs to run in a 
  7528. WIN-OS/2 window session, if possible. Some exceptions exist, for example, 
  7529. CorelDraw!** and Arts & Letters**. Those programs use some very special Windows 
  7530. programming techniques, which can cause some problems in a "seamless" WIN-OS/2 
  7531. VDM. This may not happen in every user scenario but it was felt to be safer to 
  7532. install those applications as fullscreen SAVDMs. 
  7533.  
  7534. The Migrate Applications program is used: 
  7535.  
  7536.  During installation of the OS/2 Version 2.0 operating system if you have DOS, 
  7537.   OS/2, or Windows programs already installed on your hard disk. 
  7538.  If a DOS, OS/2, or Windows program is added to a working OS/2 Version 2.0 
  7539.   system. 
  7540.  
  7541. A utility, PARSEDB, is supplied to help system administrators to add an 
  7542. organization's unique applications to the migration database, or to create 
  7543. their own. 
  7544.  
  7545.  
  7546. ΓòÉΓòÉΓòÉ 18. Windows Applications ΓòÉΓòÉΓòÉ
  7547.  
  7548. OS/2 Version 2.0 provides the capability for Windows applications to run under 
  7549. OS/2 Version 2.0, using its WIN-OS/2 component.  With this support, 
  7550. applications written for Windows 3.0 and Windows 2.x can coexist and execute 
  7551. with OS/2 and DOS applications in the same machine under OS/2 Version 2.0. 
  7552.  
  7553. Figure "Windows Applications Running under OS/2 Version 2.0" 
  7554.  
  7555. Each Windows application executes as a protected mode process within a VDM. As 
  7556. such, Windows applications are subject to the same application protection 
  7557. facilities provided to other protected mode applications (both OS/2 and MVDM 
  7558. tasks) under OS/2 Version 2.0.  Windows applications are protected from other 
  7559. Windows applications and from DOS and OS/2 applications executing in the 
  7560. system.  This is in contrast to the native Windows 3.0 environment, where 
  7561. protection is limited to DOS applications (Windows applications share a common 
  7562. address space), and is only available when Windows is running in standard or 
  7563. 386 enhanced modes. 
  7564.  
  7565. The execution of Windows applications in a protected environment allows these 
  7566. applications to take full advantage of the pre-emptive multitasking 
  7567. capabilities of OS/2 Version 2.0, with full pre-emptive multitasking between 
  7568. Windows applications, OS/2 applications and DOS applications.  This is again in 
  7569. contrast to the native Windows 3.0 environment, where pre-emptive multitasking 
  7570. is available only for DOS applications and only when Windows 3.0 is running in 
  7571. enhanced mode, thereby impacting performance and preventing many applications 
  7572. written for previous versions of Windows from executing.  OS/2 Version 2.0 has 
  7573. no such restriction. 
  7574.  
  7575.  
  7576. ΓòÉΓòÉΓòÉ 18.1. Windows 3.0 Execution Modes ΓòÉΓòÉΓòÉ
  7577.  
  7578. The native Windows 3.0 environment has three execution modes, though the 
  7579. options available to any user depend upon the machine's processor and the 
  7580. amount of installed memory. These modes are important, as they are relevant, to 
  7581. the discussion later of the way in which OS/2 runs Windows applications. The 
  7582. initial description of each mode comes from the Microsoft Windows User's Guide. 
  7583.  
  7584.  
  7585. ΓòÉΓòÉΓòÉ 18.1.1. Real Mode ΓòÉΓòÉΓòÉ
  7586.  
  7587. Real Mode:  An operating mode that Windows runs in to provide maximum 
  7588.             compatibility with versions of Windows applications prior to 3.0. 
  7589.             Real mode is the only mode available for computers with less than 
  7590.             1MB of extended memory. 
  7591.  
  7592. Real mode is equivalent to previous versions of Windows (2.x), and can address 
  7593. 640KB of conventional memory, plus LIM EMS Version 4.0 expanded memory. 
  7594. Extended memory can be used for a virtual disk or disk caching only. 
  7595.  
  7596. Real mode requires an 8088 processor or above, and 640KB of installed memory. 
  7597. Real mode requires 384KB of free conventional memory after DOS and other memory 
  7598. resident software, including network drivers, is loaded. 
  7599.  
  7600. Real mode is supported for Windows and its applications under OS/2 Version 2.0, 
  7601. in either of two ways: 
  7602.  
  7603.  The WIN-OS/2 kernel provided by OS/2 Version 2.0 may be used to run Windows 
  7604.   applications in real mode. 
  7605.  
  7606.  The commercially available Windows 3.0 product may be run in real mode in a 
  7607.   VDM, and real mode applications started from within this VDM by the Windows 
  7608.   Program Manager. 
  7609.  
  7610. Note that the commercially available Windows product cannot be run in standard 
  7611. or enhanced modes in a VDM due to Windows' memory management architecture; 
  7612. Windows assumes that it is a DPMI host and cannot act as a DPMI client.  Many 
  7613. Windows applications run quite adequately in real mode; in fact, some 
  7614. applications written for Windows 2.x cannot run in any other mode. 
  7615.  
  7616.  
  7617. ΓòÉΓòÉΓòÉ 18.1.2. Standard Mode ΓòÉΓòÉΓòÉ
  7618.  
  7619. Standard Mode:  The normal operating mode for running Windows. This mode 
  7620.                 provides access to extended memory and also lets you switch 
  7621.                 among non-Windows applications. 
  7622.  
  7623. Standard mode uses the 80286 processor's protected mode to provide direct 
  7624. access for Windows and Windows applications to up to 16MB of extended memory. 
  7625. Expanded memory for DOS applications is only supported with physical expanded 
  7626. memory cards (emulation of expanded memory using extended memory is not 
  7627. supported). 
  7628.  
  7629. Standard mode requires an 80286 processor or above, and at least 1MB of 
  7630. installed memory, with a minimum 192KB of free extended memory.  The XMS driver 
  7631. HIMEM.SYS must also be loaded.  Windows applications must be written to comply 
  7632. with the memory management rules for Windows 3.0 in order to run in standard 
  7633. mode. 
  7634.  
  7635. Standard mode is recommended by Microsoft when running only Windows 
  7636. applications (that is, no DOS applications) in certain configurations, even on 
  7637. an 80386 machine. In the Windows 3.0 manual, on page 429, it is suggested that 
  7638. users running only Windows 3.0 applications should run in standard mode, even 
  7639. on 80386 systems with 2-3MB of memory, as there is a performance improvement in 
  7640. doing so. 
  7641.  
  7642. Standard mode is necessary for some Windows applications (for example, 
  7643. Microsoft Excel** Version 3.0). To accommodate such applications, OS/2 Version 
  7644. 2.0 must provide additional support.  Basically, these applications need to 
  7645. access DPMI services for extended memory support, which is available under 
  7646. Windows 3.0 when running in standard or enhanced modes.  See DOS Protected Mode 
  7647. Interface for further information on DPMI support under OS/2 Version 2.0. 
  7648.  
  7649. The other requirement is to supply Windows services to Windows applications. 
  7650. This service is provided in OS/2 Version 2.0 by modifying the Windows kernel 
  7651. and running it in standard mode in a VDM. As part of the joint development and 
  7652. cross-licensing agreement between IBM and Microsoft, IBM has access to the 
  7653. Windows source code. IBM has modified the source to provide a Windows kernel 
  7654. (WIN-OS/2)  capable of running as a DPMI client within a VDM (the retail 
  7655. version of Windows 3.0 can only function as a DPMI host), and includes this 
  7656. kernel as part of the OS/2 Version 2.0 product. 
  7657.  
  7658. OS/2 therefore supports Windows applications running in standard mode in a VDM. 
  7659. Use of the VDM design, which provides a self-contained DOS environment, means 
  7660. that the environment is identical, from the application's point of view, to 
  7661. running under Windows loaded in standard mode, on DOS. This design therefore 
  7662. provides the maximum compatibility with the DOS/Windows environment. In fact, 
  7663. it offers a wider range of compatibility, since Windows 2.x applications, which 
  7664. require real mode operation under Windows 3.0 in DOS, can be run concurrently 
  7665. with Windows 3.0 applications running in standard mode.  This combination is 
  7666. not possible at the same time under DOS/Windows 3.0. 
  7667.  
  7668.  
  7669. ΓòÉΓòÉΓòÉ 18.1.3. 386 Enhanced Mode ΓòÉΓòÉΓòÉ
  7670.  
  7671. 386 Enhanced Mode:  A mode that Windows runs in to access the virtual memory 
  7672.                     capabilities of the Intel 80386 processor. This mode allows 
  7673.                     Windows to use more memory than is physically available and 
  7674.                     to provide multi-tasking for non-Windows applications. 
  7675.  
  7676. 386 enhanced mode uses the 80386 processor's protected mode to provide direct 
  7677. access for Windows and Windows applications to up to 16MB of extended memory. 
  7678. In addition, the virtual 8086 mode of the 80386 is used to provide multiple DOS 
  7679. environments for non-Windows applications. Most DOS applications can be run in 
  7680. a window.  Virtual memory support is provided, for Windows applications only, 
  7681. using the demand paging feature of the 80386 processor. 
  7682.  
  7683. 386 enhanced mode requires an 80386 processor or above, at least 2MB of 
  7684. installed memory, with a minimum 1MB of free extended memory.  The XMS driver 
  7685. HIMEM.SYS must also be loaded. Windows applications must be written to comply 
  7686. with the memory management rules for Windows 3.0 to run in 386 enhanced mode. 
  7687.  
  7688. The 386 enhanced mode of Windows 3.0 provides a number of additional 
  7689. capabilities over standard mode: 
  7690.  
  7691.  The capability for pre-emptive multitasking  of DOS sessions 
  7692.  
  7693.  Demand paging for efficient virtual memory. 
  7694.  
  7695. Both of these capabilities are provided by OS/2 Version 2.0 itself for both DOS 
  7696. and Windows applications, independent of the Windows kernel.  There is hence no 
  7697. need to provide such functions within the Windows kernel. 
  7698.  
  7699. There are, however, a small number of Windows applications which require 
  7700. enhanced mode to run.  Such applications require enhanced mode either because 
  7701. they rely on features only available in enhanced mode, such as Windows 3.0's 
  7702. permanent swap file capability (such as Caere Omnipage**), or have been coded 
  7703. using the WINMEM32.DLL, a set of routines that provide some 32-bit functions 
  7704. for Windows applications, such as Wolfram Research's Mathematica**. 
  7705.  
  7706. It is believed that there are only, at maximum, three or four such applications 
  7707. on the market, which represents less than 0.3% of Windows 3.0 applications 
  7708. (assuming Microsoft's quoted figure of 1500 Windows applications).  It is 
  7709. unlikely there will ever be many in the latter category of applications, since 
  7710. the WINMEM32.DLL is very difficult to use, and Microsoft itself warns in 
  7711. Appendix E of the Windows Programmer's Reference: "only experienced Windows 
  7712. application programmers with extensive experience writing assembly-level code 
  7713. should attempt to use these functions in an application." 
  7714.  
  7715. This warning is necessary because even something as basic as memory management 
  7716. using these routines can be very complex, and requires the programmer to create 
  7717. assembly language interfaces between the 16- and 32-bit parts of a program 
  7718. (note that such "thunks" are provided by OS/2 Version 2.0 between 16-bit and 
  7719. 32-bit modules; see OS/2 Version 2.0 - Volume 1:  Control Program).  Charles 
  7720. Petzold, possibly the most widely respected authority on Windows programming, 
  7721. whose book on the subject is a standard reference work, concluded on this 
  7722. subject that "something is seriously wrong when memory access becomes 
  7723. difficult", and contrasted the current Windows approach with the ease of 32-bit 
  7724. memory management under OS/2 Version 2.0. 
  7725.  
  7726. Applications which require enhanced mode will not be supported by OS/2 Version 
  7727. 2.0. Support of this mode requires Windows to run at the Ring 0 privilege level 
  7728. in the 80386 processor, which allows Windows or a Windows application to access 
  7729. all system memory and resources, including those belonging to the operating 
  7730. system itself.  This could result in a serious breach of system integrity, and 
  7731. is therefore not permitted under OS/2 Version 2.0. 
  7732.  
  7733. So, although there will almost certainly be a very small minority of Windows 
  7734. applications that will not run under OS/2 Version 2.0, the vast majority will 
  7735. run, and in a mode which allows access to their full function.  Indeed, to the 
  7736. Windows application, the environment will appear exactly the same as if the 
  7737. application were running under DOS/Windows in standard mode. 
  7738.  
  7739.  
  7740. ΓòÉΓòÉΓòÉ 18.2. Windows Applications under OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  7741.  
  7742. Under OS/2 Version 2.0, Windows applications are treated as special cases of 
  7743. DOS applications, which need a special environment in which to run.  Therefore, 
  7744. the key to Windows application compatibility is to provide these applications 
  7745. with as similar an environment as possible to that experienced under DOS, while 
  7746. taking advantage of the inherent design superiority of OS/2. 
  7747.  
  7748.  
  7749. ΓòÉΓòÉΓòÉ 18.2.1. Supported Components ΓòÉΓòÉΓòÉ
  7750.  
  7751. The following components of Windows 3.0 are supported and available within the 
  7752. OS/2 V2.0 Windows kernel: 
  7753.  
  7754.  Windows real mode kernel (WINOS2.COM and KERNEL.EXE) 
  7755.  
  7756.  Modified Windows standard mode kernel (OS2K286.EXE) 
  7757.  
  7758.  Modified DOS Extender (VDPX.SYS) 
  7759.  
  7760.  Print Manager (Spool Function) 
  7761.  
  7762.  Program Manager: 
  7763.  
  7764.    - Permits the starting of multiple Windows applications in a VDM 
  7765.    - Permits switching between Windows applications in the VDM 
  7766.  
  7767.  Help Manager 
  7768.  
  7769.  Video device drivers 
  7770.  
  7771.  Keyboard, mouse and communications device drivers 
  7772.  
  7773.  Task Manager 
  7774.  
  7775.  Windows user and GDI DLLs 
  7776.  
  7777.  Printer device drivers 
  7778.  
  7779.  Clipboard support 
  7780.  
  7781.  Setup, with only one function left in order to install Windows network device 
  7782.   drivers (DLLs). 
  7783.  
  7784.   Note:   This is really not necessary to do if you are already running any 
  7785.           network requester code under OS/2 itself. This would be transparent 
  7786.           to the entire system and therefore every VDM and WIN-OS/2 session 
  7787.           will have full access to the network, printers, files, etc. 
  7788.  
  7789.  Control Panel, with functions limited to: 
  7790.  
  7791.    - Printer Install 
  7792.    - Color 
  7793.    - Fonts 
  7794.    - Sound 
  7795.    - Mouse 
  7796.    - International 
  7797.    - KBD (Keyboard rate). 
  7798.  
  7799. The Clock program is available in a Multiple Application VDM (MAVDM) (see 
  7800. Methods of Execution). 
  7801.  
  7802. The following Microsoft Windows 3.0 components are not included within OS/2 
  7803. V2.0 (even though they would run just as any other Windows application): 
  7804.  
  7805.  File Manager 
  7806.  Systems Editor (SYSEDIT) 
  7807.  Games 
  7808.  Write 
  7809.  Terminal 
  7810.  Notepad 
  7811.  Cardfile 
  7812.  Calendar 
  7813.  Calculator 
  7814.  PIF Editor 
  7815.  Paintbrush 
  7816.  Recorder 
  7817.  Wallpaper bitmaps 
  7818.  
  7819. For each of these functions, equivalent capabilities are provided by OS/2 
  7820. Version 2.0, or these functions are not required within the OS/2 Version 2.0 
  7821. environment. 
  7822.  
  7823. Multimedia Extensions (MME) for Windows 
  7824.  
  7825. Multimedia Extensions for Windows can be installed under WIN-OS/2 and are fully 
  7826. supported. 
  7827.  
  7828. Some multimedia applications may require more than the default DPMI memory. If 
  7829. that happens, the WIN-OS/2-Setting DPMI_MEMORY_LIMIT should be adjusted to the 
  7830. appropriate value. 
  7831.  
  7832.  
  7833. ΓòÉΓòÉΓòÉ 18.2.2. Methods of Execution ΓòÉΓòÉΓòÉ
  7834.  
  7835. Windows applications may be run under OS/2 Version 2.0 in six ways: 
  7836.  
  7837.  The original licensed Windows V3.0 or Windows V2.x may be started in a VDM, 
  7838.   and will allow Windows V3.0 and Windows V2.x, and its applications, to be run 
  7839.   in real mode. 
  7840.  
  7841.  A Single Application VDM (SAVDM) may be started, for a single Windows 
  7842.   application. The icon supplied with the Windows application will be defined 
  7843.   within the Workplace Shell desktop. 
  7844.  
  7845.  A Multiple Application VDM (MAVDM) may be started, which activates the 
  7846.   Windows Program Manager, allowing the user to access a number of Windows 
  7847.   applications. 
  7848.  
  7849.  A Separate "seamless" WIN-OS/2 VDM may be used, which is basically a SAVDM 
  7850.   running in its own window under the Workplace Shell.  See "Seamless" WIN-OS/2 
  7851.   VDM below for further information. 
  7852.  
  7853.  A common "seamless" WIN-OS/2 VDM may be used, which is a special kind of 
  7854.   MAVDM. WIN-OS/2 will start all "seamless" WIN-OS/2 VDMs in a single session, 
  7855.   but in separate windows running under the Workplace Shell.  See Common 
  7856.   "Seamless" WIN-OS/2 VDM below for further information. 
  7857.  
  7858.  A separate "seamless" WIN-OS/2 VDM may be used, and the WIN-OS/2 Program 
  7859.   Manager may be launched from there. This will allow to launch other Windows 
  7860.   applications from there and therefore, this would actually be a MAVDM running 
  7861.   in its own window under the Workplace Shell. Every Windows application 
  7862.   launched from there would run in its own window under the Workplace Shell but 
  7863.   share the same WIN-OS/2 kernel. 
  7864.  
  7865. No license of Windows V3.0 or Windows V2.x is necessary to run Windows 
  7866. applications, as the Windows environment is an implementation of Windows V3.0 
  7867. and Windows V2.x within OS/2 V2.0 (WIN-OS/2) itself.  Multiple instances of any 
  7868. of the above methods may be started in the same system. 
  7869.  
  7870. However, note that in the current release, "seamless" WIN-OS/2 VDMs and common 
  7871. "seamless" WIN-OS/2 VDMs may only be started on machines with VGA graphics. 
  7872. Seamless execution of Windows applications is not supported using other 
  7873. graphics modes. 
  7874.  
  7875. The following applications are started (iconized) when the first VDM (either 
  7876. SAVDM or MAVDM) is started: 
  7877.  
  7878.  Modified Windows Clipboard Viewer Program 
  7879.  
  7880.  DDE Server/Agent Application 
  7881.  
  7882.  Presentation Manager icon 
  7883.  
  7884.  Task Manager (no icon) 
  7885.  
  7886.  Windows Program Manager (not visible in a SAVDM) 
  7887.  
  7888.  Clock (MAVDM only) 
  7889.  
  7890.  Windows Control Panel (MAVDM only). 
  7891.  
  7892. Each of these methods is described in the following sections. 
  7893.  
  7894. Single Application VDM (SAVDM) 
  7895.  
  7896. A SAVDM is the recommended way of running Windows applications under  OS/2 
  7897. Version 2.0 in a non-VGA system, such as a PS/2 with an XGA or 8514/A display 
  7898. adapter, because seamless execution is only supported with VGA graphics. Using 
  7899. a SAVDM is also recommended if the user wishes to run Windows applications in 
  7900. real mode (seamless execution is supported only in Windows standard mode). 
  7901.  
  7902. Since the Windows application runs in a self-contained Windows environment in 
  7903. its own VDM, it is fully protected from other applications, and the system is 
  7904. protected from it.  This means that if the application crashes for any reason, 
  7905. it only affects its own VDM, and thus only that one application.  Other Windows 
  7906. or DOS applications running in other VDMs are not affected, nor are OS/2 
  7907. applications.  This represents a significant improvement in reliability over 
  7908. DOS/Windows, in which a failure in one Windows application may bring down the 
  7909. entire Windows system or corrupt the data areas of other Windows programs, 
  7910. since all Windows applications and Windows itself share the same address space. 
  7911.  
  7912. Figure "Single Windows Application Running under OS/2 Version 2.0" 
  7913.  
  7914. Also, by running in SAVDMs, Windows applications are timesliced more 
  7915. effectively than in a MAVDM or native DOS/Windows environment, since each 
  7916. application is under the control of OS/2's scheduler and its pre-emptive 
  7917. multitasking.  In a MAVDM environment, all Windows applications are still 
  7918. subject to the cooperative multitasking under Windows itself. 
  7919.  
  7920. Ctrl-Esc is the key combination used to display the Windows "Window List". 
  7921.  
  7922. Alt-Esc is the key combination used to switch to the next session as defined in 
  7923. the Workplace Shell. 
  7924.  
  7925. The SAVDM provides a simple approach to Presentation Manager integration.  The 
  7926. application is loaded from the Workplace Shell in a very similar way to a DOS 
  7927. application, and the user may easily switch back to Presentation Manager, as 
  7928. well as share data via clipboard or DDE with other Windows or Presentation 
  7929. Manager  applications. The icon displayed on the Workplace Shell desktop is the 
  7930. application's own Windows icon. 
  7931.  
  7932. Each SAVDM will indicate the Windows execution mode based on the file type 
  7933. specified in the EXE header of the Windows application. Real mode will be 
  7934. indicated for Windows applications written for versions of Windows prior to 
  7935. 3.0.  Auto-Select (real or standard mode) is selected by default for Windows 
  7936. 3.0 applications, based on processor type. 
  7937.  
  7938. Multiple Application VDM (MAVDM) 
  7939.  
  7940. The MAVDM is almost identical to running Windows 3.0 on a DOS-based machine. 
  7941. The MAVDM uses the Windows 3.0 Program Manager to start multiple Windows 
  7942. applications within the same VDM, running on a separate Windows desktop. It 
  7943. therefore provides maximum "look and feel" compatibility for the DOS/Windows 
  7944. user migrating to OS/2 Version 2.0. 
  7945.  
  7946. Note that the use of a MAVDM or the common "seamless" WIN-OS/2 VDM  is a 
  7947. requirement where Windows applications must communicate with one another via 
  7948. shared memory. 
  7949.  
  7950. Ctrl-Esc is used within the VDM to display the Windows "Window List". 
  7951.  
  7952. Alt-Esc is used to switch to the next session defined in the Workplace Shell. 
  7953.  
  7954. For a MAVDM, the Workplace Shell icon will represent the MAVDM itself, rather 
  7955. than the applications executing within the VDM.  Terminating an application 
  7956. within the VDM will not terminate the VDM itself.  The user must select Exit 
  7957. Windows in the Windows Program Manager to terminate the VDM, or close the VDM 
  7958. from the Workplace Shell. 
  7959.  
  7960. In the MAVDM and the common "seamless" WIN-OS/2 VDM environment, all Windows 
  7961. applications are still subject to the cooperative multitasking of Windows 
  7962. itself.  Since several Windows applications are typically loaded in the same 
  7963. VDM, the MAVDM environment shares some of the pitfalls of DOS/Windows in terms 
  7964. of robustness.  If one Windows application crashes within a MAVDM,  it may 
  7965. cause all the applications within that VDM to fail.  However, the effect is 
  7966. only within that VDM; other VDMs running DOS or Windows applications, and other 
  7967. processes executing under OS/2 Version 2.0, are not affected and continue 
  7968. execution.  So even here there are benefits from running Windows applications 
  7969. under OS/2, for greater resilience from system crashes.  Furthermore, the MAVDM 
  7970. environment provides additional error checking and handling over that provided 
  7971. by Windows 3.0 itself. 
  7972.  
  7973. "Seamless" WIN-OS/2 VDM 
  7974.  
  7975. One of the goals of OS/2 2.0 is to be the integrating platform of choice; that 
  7976. is, to provide a desktop environment from which all types of applications: 
  7977.  
  7978.  16-bit OS/2 
  7979.  32-bit OS/2 
  7980.  DOS 
  7981.  Windows 
  7982.  
  7983. may be executed in a uniform manner.  Although OS/2 V2.0 is able to support 
  7984. Windows applications effectively in SAVDMs, the additional ability to launch a 
  7985. Windows application from a Workplace Shell object, and execute it on the OS/2 
  7986. desktop along with Presentation Manager and DOS applications, achieves the goal 
  7987. of creating an environment that is explicitly simple and uniform enough that 
  7988. the end user need not be concerned with the implicit differences between the 
  7989. types of applications that need to be executed in it.  OS/2 V2.0 will concern 
  7990. itself with the differences and "seamlessly" accommodate the applications. 
  7991. This level of support extends not only to execution but to installation and 
  7992. configuration of the application as well. 
  7993.  
  7994. Figure "Single Windows Application(s) Running "Seamless" on the OS/2 Version 
  7995. 2.0 Desktop" 
  7996.  
  7997. The appearance of Windows applications on the Workplace Shell desktop requires 
  7998. that the Windows video device driver and the Presentation Manager video device 
  7999. driver communicate and coordinate their access of the video hardware.  Each 
  8000. device driver effectively "owns" its area of the screen.  Allowing the Windows 
  8001. display device driver to directly access the video hardware avoids the more 
  8002. cumbersome process of a complete task switch.  However, this hardware access 
  8003. poses integrity problems in the areas of simultaneous access of hardware, 
  8004. rectangle invalidation handling, window management, and the exchange of window 
  8005. state information between Presentation Manager and seamless VDMs supported by 
  8006. separate video device drivers. 
  8007.  
  8008. To address these problems, a high performance virtual device driver named 
  8009. (VWIN.SYS), capable of interprocess communication, was created.  This VDD 
  8010. serializes the simultaneous accesses to the hardware, oversees the exchange of 
  8011. window state information between Presentation Manager and seamless VDMs, and 
  8012. establishes the addressability of Presentation Manager resources (either 
  8013. directly or indirectly) by the Windows display device driver. 
  8014.  
  8015. When the system is initialized, the Presentation Manager display driver calls 
  8016. the VWIN.SYS driver, and passes a pointer to an array of structures that 
  8017. specify the protocol required to enable the Windows device driver to access 
  8018. Presentation Manager resources.  To prevent a seamless Windows application from 
  8019. hanging the entire Workplace Shell desktop, the Windows video device driver and 
  8020. the Presentation Manager video device driver together implement and monitor a 
  8021. VDM "heartbeat" or counter.  This counter is stored in the Presentation Manager 
  8022. display driver's data area and is made available to the Windows display driver. 
  8023.  
  8024. The "heartbeat" counter information is made available to the Windows DD to 
  8025. indicate that hardware access is in progress by the Windows DD. The "heartbeat" 
  8026. counter is incremented by the Windows DD prior to the video hardware access. If 
  8027. a Windows application is locking up the Workplace Shell desktop, it is the 
  8028. responsibility of VWIN.SYS to identify the current owner of the semaphore, 
  8029. terminate the VDM and tell the Presentation Manager DD to clean up. 
  8030.  
  8031. In the event that the Presentation Manager display device driver requests 
  8032. hardware resources and the time interval allotted for this access to occur is 
  8033. exceeded, then: 
  8034.  
  8035.  1. If it is the first request, the Presentation Manager display driver records 
  8036.     the heartbeat value, process ID and thread ID of the process in control of 
  8037.     the hardware, and raises an internal flag. 
  8038.  
  8039.  2. If it is the second request, and the heartbeat value, PID and TID have not 
  8040.     changed, the Presentation Manager display driver calls the Windows display 
  8041.     driver before clearing the flag, and passes it the PID and TID. 
  8042.  
  8043.     It is the responsibility of the Windows driver to use the PID and TID to 
  8044.      identify the process that is monopolizing the hardware resources and 
  8045.      inform the Presentation Manager driver. 
  8046.  
  8047.     If it is an active, seamless VDM, WIN-OS/2 will terminate the VDM and 
  8048.      inform the Presentation Manager driver to clean up. 
  8049.  
  8050.     If the PID and TID are invalid, the Windows driver will inform the 
  8051.      Presentation Manager driver to clean up. 
  8052.  
  8053.     If the PID and TID belong to a Presentation Manager application, the 
  8054.      Windows driver will tell the Presentation Manager driver to attempt access 
  8055.      again. 
  8056.  
  8057. This algorithm is relatively simple but not totally fail-safe.  It is quite 
  8058. possible to create a serialization mechanism that would safeguard the Workplace 
  8059. Shell desktop to a greater degree.  However, when one considers the remoteness 
  8060. of the possibility of its failure (which requires a bogus PID or TID), the 
  8061. costs, in terms of a performance impact, would far outweigh the benefits 
  8062. incurred. 
  8063.  
  8064. Some important points about "seamless" WIN-OS/2 VDMs: 
  8065.  
  8066.  Note that the use of a MAVDM or a common "seamless" WIN-OS/2 VDM  is a 
  8067.   requirement where Windows applications must communicate with one another via 
  8068.   shared memory. 
  8069.  
  8070.  Only standard mode is supported in this mode of operation. 
  8071.  
  8072.  Presentation Manager must provide extensive support for this implementation 
  8073.   of WIN-OS/2.  Basically, Presentation Manager supports a "black hole" and 
  8074.   allows the WIN-OS/2 kernel to control it.  A modified WIN-OS/2 and 
  8075.   Presentation Manager display device driver is built into OS/2 Version 2.0 to 
  8076.   support this mechanism. 
  8077.  
  8078.  The "seamless" WIN-OS/2 VDM is only supported if OS/2 is configured for VGA 
  8079.   mode, because only the Windows VGA display device driver is supported.  This 
  8080.   means that, on an 8514 or XGA equipped system, the Presentation Manager 
  8081.   display device driver must be configured in VGA mode to be able to run 
  8082.   Windows applications in a "seamless" WIN-OS/2 VDM.  If the user selects a 
  8083.   higher resolution display device driver such as XGA, Windows applications may 
  8084.   only run in a SAVDM or MAVDM environment. 
  8085.  
  8086.   Notes: 
  8087.  
  8088.     1. Over time, more display device drivers will be enhanced to support this 
  8089.        seamless mode of WIN-OS/2.  Once available, installed and configured 
  8090.        appropriately, WIN-OS/2 will provide seamless execution on other 
  8091.        supported graphics modes. 
  8092.  
  8093.     2. Readers should check the ReadMe file in the Information folder for the 
  8094.        latest information on this subject.  Information in this folder explains 
  8095.        how to reconfigure the system to have seamless WIN-OS/2 support as well 
  8096.        as high resolution MAVDM and/or SAVDM sessions. 
  8097.  
  8098.  A VDD (VWIN.SYS) provides the necessary services to the Windows kernel and 
  8099.   Presentation Manager. 
  8100.  
  8101. As shown in Figure "Implementation of "Seamless" WIN-OS/2 VDM in OS/2 Version 
  8102. 2.0" PMVIOP.DLL contains a PMShield routine which is responsible for 
  8103. maintaining the entire Workplace Shell desktop, including the "black holes" 
  8104. which correspond to and are maintained by each "seamless" WIN-OS/2 VDM. 
  8105.  
  8106. WinShield is the Windows VDM's counterpart of PMShield.  The Workplace Shell 
  8107. desktop windowing state must be maintained in its entirety by this component. 
  8108. WinShield registers a service routine with VWIN.SYS, giving it the ability to 
  8109. post a message to PMShield whenever the Workplace Shell desktop state changes. 
  8110.  
  8111. Upon creation of the first "seamless" WIN-OS/2 VDM, PMShield spawns three 
  8112. dedicated threads under the Workplace Shell to specifically service its 
  8113. "seamless" WIN-OS/2 VDM clients: 
  8114.  
  8115.  Thread 1 is the IPC Read Thread, which normally suspends itself within 
  8116.   VWIN.SYS, waiting for window-related events to occur in the "seamless" 
  8117.   WIN-OS/2 VDM. The typical events sent by the WinShield are Create, Move, 
  8118.   Size, Show Activate, etc. These events are duplicated by PMShield on the 
  8119.   Workplace Shell desktop for the purpose of tracking the "black hole" windows. 
  8120.  
  8121.  Thread 2 is the Control Windows Procedure Thread that the PMShield registers 
  8122.   with PMWIN.DLL.  This thread handles all relevant events that alter the state 
  8123.   of the Workplace Shell desktop.  Once in control, this thread will broadcast 
  8124.   all Workplace Shell desktop initiated events asynchronously to all VDMs by 
  8125.   calling VWIN.SYS.  This causes a previously registered WinShield routine to 
  8126.   be dispatched, giving it an opportunity to post an asynchronous message to 
  8127.   itself. 
  8128.  
  8129.  Thread 3 is the Error Handling Thread. All non-fatal errors on all "seamless" 
  8130.   WIN-OS/2 VDM related operations will be reported through this mechanism where 
  8131.   a Presentation Manager dialog box will pop up explaining to the user what 
  8132.   went wrong. 
  8133.  
  8134. On successful creation of a "seamless" WIN-OS/2 VDM, the Presentation Manager 
  8135. Session Start thread will notify VVGA.SYS to allow the started VDM to access 
  8136. the video hardware directly. 
  8137.  
  8138. Common "Seamless" WIN-OS/2 VDM 
  8139.  
  8140. There is no visible difference between Windows applications running in a 
  8141. "seamless" WIN-OS/2 VDM and those running in a common "seamless" WIN-OS/2 VDM. 
  8142. The technical differences between them are described in the following 
  8143. paragraphs. Everything else discussed in the above section ."Seamless" WIN-OS/2 
  8144. VDM is common to both. 
  8145.  
  8146. To reduce the system resource usage in a low memory environment, users are 
  8147. given the option to start all "Seamless" WIN-OS/2 applications in the same VDM. 
  8148. This also helps to reduce startup time for Windows applications, and reduces 
  8149. the swap file space required.  By default, Windows applications migrated from a 
  8150. DOS/Windows system at OS/2 installation time are migrated to a common 
  8151. "seamless" WIN-OS/2 VDM.  The user has the option of prestarting one or more 
  8152. Windows applications in the common "seamless" WIN-OS/2 VDM by using the Startup 
  8153. folder in the Workplace Shell. 
  8154.  
  8155. There is only one common "seamless" WIN-OS/2 VDM in the system.  If the system 
  8156. is not currently configured to run "seamless" WIN-OS/2 VDMs, any Windows 
  8157. application which is defined for common "seamless" WIN-OS/2 VDM will be loaded 
  8158. and run in a fullscreen SAVDM. 
  8159.  
  8160. By default, only the first Windows program launched from the Workplace Shell as 
  8161. a "seamless" WIN-OS/2 VDM will create a new VDM.  Any subsequent Windows 
  8162. programs will share this environment, in exactly the same way as in a MAVDM 
  8163. full-screen session.  This is known as the common "seamless" WIN-OS/2 
  8164. environment. 
  8165.  
  8166. However, the user may wish to protect these Windows programs from each other, 
  8167. and to maximize the timeslicing efficiency of Windows applications. This can be 
  8168. done by checking the Separate session option on the Session page of the 
  8169. Settings notebook for any Windows program object under the Workplace Shell. 
  8170. That procedure would activate a "normal" "seamless" WIN-OS/2 VDM session. 
  8171.  
  8172. The Workplace Shell Window List will contain an entry for the common "seamless" 
  8173. WIN-OS/2 VDM itself, in addition to an entry for each Windows program running 
  8174. in this VDM  This provides also a mechanism for terminating this VDM from the 
  8175. Workplace Shell desktop, along with all the active Windows applications in it. 
  8176. As the user has a visual representation of the "contents" of the common 
  8177. "seamless" WIN-OS/2 VDM, the user knows which applications will be terminated 
  8178. if the Close option is chosen.  If the common "seamless" WIN-OS/2 VDM hangs 
  8179. because one of the Windows programs is not behaving properly, the Close option 
  8180. on the entry for the common "seamless" WIN-OS/2 VDM will close down the entire 
  8181. VDM, including all Windows programs running in it.  This behavior is similar to 
  8182. that of a MAVDM. 
  8183.  
  8184. In the MAVDM and the common "seamless" WIN-OS/2 VDM environment, all those 
  8185. Windows applications are still subject to the cooperative multitasking under 
  8186. Windows itself.  Since several Windows applications are loaded in the same VDM, 
  8187. the common "seamless" WIN-OS/2 VDM shares the same pitfalls as does the MAVDM. 
  8188. If one Windows application crashes within a common "seamless" WIN-OS/2 VDM, it 
  8189. may cause all the applications within that VDM to fail.  However, as in a 
  8190. MAVDM, the effect is only within that VDM; other VDMs running DOS or Windows 
  8191. applications, and other processes executing under OS/2 Version 2.0, are not 
  8192. affected and continue execution.  So even here there are additional benefits 
  8193. running Windows applications seamlessly under OS/2.  Furthermore, as for the 
  8194. MAVDM environment, enhancements are made to provide additional error checking 
  8195. and handling for the common "seamless" WIN-OS/2 VDM. 
  8196.  
  8197. A number of restrictions apply to the use of a common "seamless" WIN-OS/2 VDM. 
  8198. These are as follows: 
  8199.  
  8200.  The DOS settings which will be in effect for the common "seamless" WIN-OS/2 
  8201.   VDM will be those which are defined by the first Windows program to start in 
  8202.   this VDM. Changes to the settings for any subsequent Windows program in that 
  8203.   VDM will not affect the actual settings of the common "seamless" WIN-OS/2 
  8204.   VDM. To make this obvious to the user, the WIN-OS/2 Settings button on the 
  8205.   Session page of the Settings notebook is grayed for all Windows applications 
  8206.   running in the common "seamless" WIN-OS/2 VDM once it is active.  This 
  8207.   implies that WIN-OS/2 settings cannot be viewed or changed once this VDM is 
  8208.   started. 
  8209.  
  8210.  The DPMI limit for the common "seamless" WIN-OS/2 VDM is higher than when 
  8211.   defined for "seamless" WIN-OS/2 VDM, since multiple applications are likely 
  8212.   to require more DPMI memory. 
  8213.  
  8214.  Each Windows program running in the common "seamless" WIN-OS/2 VDM will have 
  8215.   the same HAPP application handle), PID (process ID), and SGID (screen group 
  8216.   ID). Any action taken on one of these values will cause that action against 
  8217.   the entire VDM and not against only a specific instance inside the common 
  8218.   "seamless" WIN-OS/2 VDM. For example, if a WinTerminateApp() call is issued, 
  8219.   which uses the HAPP as input, then all applications running within the common 
  8220.   "seamless" WIN-OS/2 VDM will be terminated.  The user will be warned by a 
  8221.   dialog that multiple Windows applications will be ended. 
  8222.  
  8223.  
  8224. ΓòÉΓòÉΓòÉ 18.3. Installing WIN-OS/2 Support Under OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  8225.  
  8226. Windows application support is provided by default during the installation of 
  8227. OS/2 Version 2.0.  If the user wishes not to install Windows support, the 
  8228. appropriate option must be chosen during OS/2 installation. 
  8229.  
  8230. The OS/2 installation program detects the video resolution of the machine on 
  8231. which it is being installed.  If Windows support is selected during "first 
  8232. time" installation, then the following configurations will be applied according 
  8233. to the detected video resolution: 
  8234.  
  8235. CGA, EGA         Configured for full-screen (only) Windows support. 
  8236.  
  8237. VGA              Configured for "seamless" WIN-OS/2 VDM support. 
  8238.  
  8239. 8514/A, XGA      During installation, a panel with the option to select 
  8240.                  seamless support (and downgrade to VGA graphics mode) is 
  8241.                  provided (see Figure "Installing Windows Support under OS/2 
  8242.                  Version 2.0").  If full-screen (only) Windows support is 
  8243.                  selected, then the higher resolution is maintained. 
  8244.  
  8245. Note:   Readers should check the ReadMe file in the Information folder for the 
  8246.         latest information on this subject.  This folder contains information 
  8247.         on how to reconfigure the system to have seamless WIN-OS/2 support as 
  8248.         well as high resolution MAVDM and/or SAVDM sessions.  Additional 
  8249.         support information for SVGA display device drivers will be provided as 
  8250.         well.  OS/2 Version 2.0 - Volume 1:  Control Program also discusses 
  8251.         several installation and configuration aspects of OS/2 V2.0. 
  8252.  
  8253. When Windows support is selected at installation time, all the files necessary 
  8254. to provide this support are installed in the following subdirectories: 
  8255.  
  8256.  \OS2\MDOS\WINOS2 
  8257.  
  8258.  \OS2\MDOS\WINOS2\SYSTEM 
  8259.  
  8260. If the user decides to install Windows application support, DOS application 
  8261. support is automatically installed.  OS/2 Version 2.0's CONFIG.SYS file is 
  8262. updated to include the above directories in the PATH statement. 
  8263.  
  8264. Since Windows real mode requires 640KB of conventional memory and several MB of 
  8265. expanded memory (EMS), the EMS virtual device driver is also required.  If the 
  8266. user did not select standard mode at installation time and wishes to add it at 
  8267. later time, the OS/2 Version 2.0 CONFIG.SYS must be modified by adding the 
  8268. following statements: 
  8269.  
  8270.  DEVICE=C:\OS2\MDOS\VDPMI.SYS (DOS Protect Mode Interface) 
  8271.  
  8272.  DEVICE=C:\OS2\MDOS\VDPX.SYS (DOS Extender Virtual Device Driver). 
  8273.  
  8274. If these device drivers are not loaded, the Windows kernel will execute in real 
  8275. mode. 
  8276.  
  8277. Windows can use expanded memory which conforms to the LIM EMS 4.0 specification 
  8278. when running in real mode. This memory is primarily used for storing background 
  8279. applications.  In a DOS/Windows environment, an appropriate Expanded Memory 
  8280. Manager must be installed.  Under OS/2 V2.0 this is not necessary, as the 
  8281. virtual device driver already provides that service. In standard mode, Windows 
  8282. may also use extended memory (XMS). 
  8283.  
  8284.  
  8285. ΓòÉΓòÉΓòÉ 18.4. Migrating to OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  8286.  
  8287. Upon completion of the installation process, the user is given the opportunity 
  8288. to migrate installed Windows applications (defined to the Windows Program 
  8289. Manager) to the OS/2 Version 2.0 Workplace Shell.  All Windows applications 
  8290. which are to be migrated must have the appropriate DOS and Windows settings 
  8291. defined in the Certified Application Database (CAD), which is shipped as a 
  8292. standard component of OS/2 Version 2.0.  See also Installing and Migrating 
  8293. Applications. 
  8294.  
  8295. Note:   Only the settings for those applications which have been certified via 
  8296.         approved IBM testing channels will be held in the Certified 
  8297.         Applications Database (CAD), and only those settings which differ from 
  8298.         the default settings will be recorded. 
  8299.  
  8300. If a referenced Windows application is found on any of the available disk 
  8301. volumes during OS/2 installation, the existing *.INI and *.GRP files will be 
  8302. read, the necessary changes applied to them, and the updated versions stored in 
  8303. the \OS2\MDOS\WINOS2 directory.  This will effectively migrate the user's 
  8304. Windows desktop, including all Windows applications, into a MAVDM, SAVDM or 
  8305. seamless environment. 
  8306.  
  8307. The CAD provides information enabling the installation procedure to 
  8308. automatically set the DOS settings for certified DOS and Windows applications. 
  8309. The user is presented with a list of the certified applications found, which 
  8310. can then be migrated. The user may select any or all of these applications. 
  8311. The CAD is searched for each of the selected applications, and DOS and/or 
  8312. Windows settings information found in the database will be used to 
  8313. automatically assign settings to applications.  Windows applications will be 
  8314. placed in a single "Windows Applications" folder.  DOS applications are placed 
  8315. in a single "DOS Applications" folder. 
  8316.  
  8317. The CAD is a binary database, generated from an ASCII database and a predefined 
  8318. tag file. Each field in the ASCII database starts with a descriptive tag that 
  8319. is associated with a value between 0-225 in the predefined tag file; the 
  8320. maximum number of tags is therefore 256.  When the binary CAD generation tool 
  8321. encounters one of the descriptive tags, it generates an entry in the binary CAD 
  8322. with a 0-255 value specified in the predefined tag file.  To add new or 
  8323. additional DOS properties, a short descriptive tag is created for the ASCII 
  8324. file and associated with an unused value between 0-255 in the predefined tag 
  8325. file. A length specification is also provided for the value in the tag file. 
  8326.  
  8327. Each field in the binary CAD starts with a predefined tag value of 0-255 that 
  8328. identifies the field. This tag is followed by a size field, which in turn is 
  8329. followed by the actual value of the field. 
  8330.  
  8331. Each application in the CAD has the following minimum information: 
  8332.  
  8333.  The filename used to start the application 
  8334.  
  8335.  The title of the application 
  8336.  
  8337.  A pointer to the next application. 
  8338.  
  8339. The filename that starts the application is used to identify the application on 
  8340. the hard drive. The next application pointer points directly to the next 
  8341. application entry in the CAD. This provides the ability to jump from one entry 
  8342. to the next without parsing all of the tags between entries in the CAD. The 
  8343. application title is displayed to the user if the application is found on the 
  8344. hard drive. The user will use this information to specify if the application is 
  8345. to be migrated. 
  8346.  
  8347. The filename extensions held in the CAD will determine what files are searched 
  8348. for; that is all EXE, COM and BAT files. 
  8349.  
  8350. When the applications have been migrated into the OS/2 Version 2.0 Workplace 
  8351. Shell, information for DOS applications is stored in the OS2.INI file.  Windows 
  8352. settings for Windows applications are stored in the WIN.INI file, while their 
  8353. DOS-related settings are stored in the OS2.INI file. 
  8354.  
  8355.  
  8356. ΓòÉΓòÉΓòÉ 18.5. Defining Windows Applications ΓòÉΓòÉΓòÉ
  8357.  
  8358. As mentioned in the previous section, Windows applications may be automatically 
  8359. migrated to the Workplace Shell desktop at OS/2 installation time. However, for 
  8360. applications which are not defined in the Certified Application Database, or 
  8361. which are installed after OS/2 installation, a Workplace Shell object may be 
  8362. created from a template in the Templates folder.  For such applications, the 
  8363. WIN-OS/2 application execution environment is defined to the Workplace Shell 
  8364. using the Program page of the program object's Settings notebook. 
  8365.  
  8366. Figure "Defining a Windows Application to OS/2 Version 2.0" 
  8367.  
  8368. The Session page allows the user to change Windows settings via the Windows 
  8369. Settings dialog. This page defines whether the Windows kernel will execute in 
  8370. real, standard, or Auto-Select mode. Auto-Select mode is highlighted as the 
  8371. default.  All DOS settings are selectable for Windows applications via the 
  8372. Windows Setting dialog;  Windows settings are included in the same list. 
  8373.  
  8374.  
  8375. ΓòÉΓòÉΓòÉ 18.5.1. Defining a Single Application VDM (SAVDM) ΓòÉΓòÉΓòÉ
  8376.  
  8377. For a SAVDM, the Windows application name is entered into the Path and Filename 
  8378. field on the Program page of the Settings notebook. The Workplace Shell then 
  8379. determines the application type. Upon detecting that the application is a 
  8380. Windows application, the Program Type in the Session page of the notebook will 
  8381. be set to Windows Full Screen. When a user interactively creates a program 
  8382. object for a Windows  application  and the Workplace Shell determines it is a 
  8383. real mode application, Windows Full Screen will be marked as the default and 
  8384. the application will be started as a SAVDM. 
  8385.  
  8386. Each SAVDM has its own icon on the Workplace Shell desktop, for the application 
  8387. within the SAVDM.  This icon is the normal Windows icon for this application. 
  8388. The icon title text will be the text specified in the Title field in the 
  8389. General page of the Settings notebook. 
  8390.  
  8391.  
  8392. ΓòÉΓòÉΓòÉ 18.5.2. Defining a Multiple Application VDM (MAVDM) ΓòÉΓòÉΓòÉ
  8393.  
  8394. When defining a MAVDM, the user specifies WINOS2.COM for the Path and Filename 
  8395. field in the Program page of the Settings notebook.  As explained above, the 
  8396. Workplace Shell detects that the application is a Windows application and sets 
  8397. the Program Type field in the Session page to Windows Full Screen. 
  8398.  
  8399. The user may also define one or more Windows applications which will be 
  8400. activated when the VDM is started. This is achieved as follows: 
  8401.  
  8402.  1. The applications to be started are specified in the Parameters field of the 
  8403.     Program dialog.  Full path name and parameters should be specified. 
  8404.  
  8405.     The syntax for the parameters field is: 
  8406.  
  8407.             /R|/S [{][!|^]App1 App-parms [,] [!|^]App2 App-parms
  8408.  
  8409.     /R Windows real mode 
  8410.  
  8411.     /S Windows standard mode These parameter are active for the whole VDM and 
  8412.     not on an application base. 
  8413.  
  8414.     [ ] Optional Parameters 
  8415.  
  8416.     ! Start the Windows Application Minimized 
  8417.  
  8418.     ^ Start the Windows Application Maximized. No blank must be specified 
  8419.     between '!' or '^' and the application name. 
  8420.  
  8421.     A MAVDM will be created if one of the following are present: 
  8422.  
  8423.     {} Braces 
  8424.  
  8425.     Comma separating the application names 
  8426.  
  8427.     An application name is not passed as a parameter. 
  8428.  
  8429.     If neither the exclamation mark nor the caret is specified, the Windows 
  8430.     application will start "normalized", approximately one third of the screen 
  8431.     size. 
  8432.  
  8433.     Changes are effective immediately and are saved when the Settings notebook 
  8434.     is closed or when the system is shut down.  The Default button resets all 
  8435.     settings to their previous values. 
  8436.  
  8437.  2. In the Session dialog WIN-OS/2 full screen must be selected. 
  8438.  
  8439. The icon will be the Windows full-screen icon defined by WINOS2.COM. 
  8440. Individual icons for applications running in the MAVDM are not displayed on the 
  8441. Workplace Shell desktop. 
  8442.  
  8443.  
  8444. ΓòÉΓòÉΓòÉ 18.5.3. Defining a "Seamless" WIN-OS/2 VDM ΓòÉΓòÉΓòÉ
  8445.  
  8446. In order to obtain the highest integration of the Windows V3.0 and Windows V2.x 
  8447. application into the OS/2 V2.0 Workplace Shell, the following definitions must 
  8448. be provided in order to have the application execute in seamless mode: 
  8449.  
  8450.  1. Select the Program page of the program object's Settings notebook. 
  8451.  
  8452.  2. Enter the Windows application name in the Path and Filename field. A fully 
  8453.     qualified path and filename is necessary. 
  8454.  
  8455.  3. Select the Session page of the program reference object's Settings 
  8456.     notebook. 
  8457.  
  8458.  4. Click on the WIN-OS/2 window radio button. 
  8459.  
  8460.  5. All DOS settings are selectable for Windows applications via the Windows 
  8461.     Settings page dialog; Windows settings are included in the same list. 
  8462.  
  8463. The "WIN-OS/2 Window" radio button indicates that the associated Windows 
  8464. application program is to be initiated in a "seamless" Windows VDM.  This is a 
  8465. single application VDM.  However, the WIN-OS/2 Program Manager may be 
  8466. registered with the Workplace Shell as a "seamless" WIN-OS/2 program object. 
  8467. Once the Program Manager is up and running, the user may launch any other 
  8468. Windows program from it.  Of course, this assumes that other Windows programs 
  8469. were installed through the Program Manager, and that they all run in the same 
  8470. WIN-OS/2 session. 
  8471.  
  8472. A new parameter is added to the SYSTEM.INI file: 
  8473.  
  8474.               WOS2VDMApps=!clipwos2,!ddeagent
  8475.  
  8476. The WIN-OS/2 Program Manager reads this line for "seamless" WIN-OS/2 VDM, to 
  8477. determine which applications to pre-start. 
  8478.  
  8479. Since "WIN-OS/2 Window" is the default Windows application setting, all Windows 
  8480. program objects that are created through the Windows Migration utility (for 
  8481. standard mode Windows applications) will default to that setting. If a user 
  8482. chooses to execute a Windows application by double clicking its program file's 
  8483. icon in the Drives folder, rather than its program object icon (if any), then 
  8484. the Workplace Shell will attempt to initiate it in a "seamless" Windows 
  8485. environment. 
  8486.  
  8487.  
  8488. ΓòÉΓòÉΓòÉ 18.6. Starting Windows Applications ΓòÉΓòÉΓòÉ
  8489.  
  8490. The following methods may be used to start Windows applications: 
  8491.  
  8492.  1. Select the application's program file from within the Drives folder. This 
  8493.     method is not recommended, as it will not pick up any optimized DOS and/or 
  8494.     Windows settings. 
  8495.  
  8496.  2. Enter the application name at an OS/2 command line prompt.  This method is 
  8497.     not recommended, for the same reason as stated above. 
  8498.  
  8499.  3. Install the application in a folder, in the Workplace Shell desktop as 
  8500.     described in Defining Windows Applications, and start it by double-clicking 
  8501.     the mouse on its icon.  This is the preferred method for starting a Windows 
  8502.     application. 
  8503.  
  8504. If the application is started from either the Drives Folder or an OS/2 command 
  8505. prompt, a SAVDM will be created. If the application is started from an icon, 
  8506. either a SAVDM, a MAVDM or a "seamless" WIN-OS/2 VDM will be created, depending 
  8507. on how the application was defined at installation. 
  8508.  
  8509.  
  8510. ΓòÉΓòÉΓòÉ 18.6.1. SAVDM ΓòÉΓòÉΓòÉ
  8511.  
  8512. A SAVDM is created for the execution of a single Windows application.  The 
  8513. Workplace Shell actually starts WINOS2.COM as the application in the VDM, and 
  8514. the application to be started in the VDM is passed as a parameter to WINOS2. 
  8515. This process is transparent to the user; the definition of the SAVDM in the 
  8516. Settings notebook uses the Windows application name only. 
  8517.  
  8518. If WINOS2 is to execute in real mode, the /r option will be automatically 
  8519. inserted into the parameter list for the VDM creation, based on the WIN-OS/2 
  8520. settings.  If standard mode was highlighted, /s is passed as a parameter to 
  8521. WINOS2.  The default is to pass no Windows options, only the application name. 
  8522.  
  8523. When the Windows application is terminated, WINOS2.COM terminates, which in 
  8524. turn causes the VDM to be terminated. 
  8525.  
  8526.  
  8527. ΓòÉΓòÉΓòÉ 18.6.2. MAVDM ΓòÉΓòÉΓòÉ
  8528.  
  8529. In the case of a MAVDM, the Windows Program Manager is loaded in the VDM, 
  8530. transparently to the user.  The Program Manager's window is displayed 
  8531. maximized, and applications are then launched from the Windows Program Manager. 
  8532. In this case, the Workplace Shell's Window List will display the name of the 
  8533. Windows kernel (WINOS2.COM) executing in the VDM.  It will not show each 
  8534. individual Windows application running within that MAVDM.  This is different 
  8535. from a SAVDM, where the Workplace Shell's Window List will display the name of 
  8536. the Windows application. 
  8537.  
  8538.  
  8539. ΓòÉΓòÉΓòÉ 18.6.3. "Seamless" WIN-OS/2 VDM ΓòÉΓòÉΓòÉ
  8540.  
  8541. OS/2 Version 2.0 does not allow a "seamless" WIN-OS/2 VDM to be started from a 
  8542. DOS or OS/2 command prompt, nor is there any programmed interface for starting 
  8543. a "seamless" WIN-OS/2 VDM application from a Presentation Manager application. 
  8544. In addition, a SAVDM or MAVDM cannot be switched to a "seamless" WIN-OS/2 VDM 
  8545. once the virtual DOS machine is running. 
  8546.  
  8547. The "seamless" WIN-OS/2 VDM execution mode allows Windows applications to run 
  8548. from the Workplace Shell desktop in a manner that is virtually 
  8549. indistinguishable from other OS/2 and DOS applications.  Double clicking a 
  8550. "seamless" WIN-OS/2 VDM application icon will cause that application to be run 
  8551. in a window on the Workplace Shell desktop. This single application "seamless" 
  8552. WIN-OS/2 VDM environment will be a separate Windows VDM, where the Program 
  8553. Manager is not visible. 
  8554.  
  8555. In order to be perceived as a compatible part of the Workplace Shell 
  8556. environment, the "seamless" WIN-OS/2 VDM application's execution must be 
  8557. controllable in the same manner as the execution of other OS/2 and DOS 
  8558. applications. This has several implications: 
  8559.  
  8560.  The name of each active "seamless" WIN-OS/2 VDM application will be included 
  8561.   in the Workplace Shell Task List. 
  8562.  
  8563.  Each "seamless" WIN-OS/2 VDM supports an appropriate context menu. 
  8564.  
  8565.  The user is able to cycle through all open Workplace Shell windows in the 
  8566.   standard Alt-Esc manner. 
  8567.  
  8568.  The minimize/hide icons on Windows applications function consistently with 
  8569.   other such icons on the Workplace Shell desktop. 
  8570.  
  8571.  The window controls on a "seamless" WIN-OS/2 VDM window operate in the same 
  8572.   fashion as analogous Workplace Shell controls. The display style of the 
  8573.   window controls on a "seamless" WIN-OS/2 VDM window will be "Windows-style" 
  8574.   however. 
  8575.  
  8576.  When a "seamless" WIN-OS/2 VDM Windows application terminates, its Workplace 
  8577.   Shell window is also terminated. 
  8578.  
  8579. This approach allows the appearance of a Windows application executing in a 
  8580. "seamless" WIN-OS/2 VDM to conform as closely as possible to that seen when 
  8581. running in a native DOS/Windows environment, while its behavior is as close as 
  8582. possible to that of a normal Presentation Manager/Workplace Shell application. 
  8583.  
  8584. If You can't get a "Seamless" WIN-OS/2 VDM to Work 
  8585.  
  8586. Starting a Windows application requires a number of configuration options to be 
  8587. correctly completed prior to starting the application.  Failure to do so may 
  8588. result in the application failing to start.  This is typically due to one of 
  8589. three problems: 
  8590.  
  8591.  1. Failures that are due to the configuration of the overall OS/2 V2.0 system. 
  8592.  
  8593.  2. Failures that are due to the configuration of the overall Windows 
  8594.     environment. 
  8595.  
  8596.  3. Failures that are due to the nature of a particular Windows  application. 
  8597.  
  8598. The first two classes result from not being "seamless capable"; that is, some 
  8599. part of the system's configuration is not set up properly for "seamless" 
  8600. WIN-OS/2 VDM operation.  For example: 
  8601.  
  8602.  An OS/2 V2.0 video device driver other than the "seamless" VGA driver is 
  8603.   installed. 
  8604.  
  8605.  VWIN.SYS is not installed, due to the following line being missing in 
  8606.   CONFIG.SYS: 
  8607.  
  8608.                   DEVICE=C:\OS2\MDOS\VWIN.SYS
  8609.  
  8610.  The Windows video device driver referenced by the SDISPLAY.DRV= statement in 
  8611.   SYSTEM.INI file does not point to the "seamless" Windows VGA device driver. 
  8612.   The correct entry in the SYSTEM.INI is: 
  8613.  
  8614.                   SDISPLAY=SWINVGA.DRV
  8615.  
  8616. The third class arises because the "seamless" execution environment will be a 
  8617. SAVDM that runs in standard mode only.  This means that real mode Windows 
  8618. applications will not be able to run in "seamless" WIN-OS/2 VDM ("seamless" 
  8619. VDMs).  The Workplace Shell is able to gracefully handle the initiation of real 
  8620. mode Windows applications, because it can determine the mode of a Windows 
  8621. application from its program header.  Such Windows applications will be 
  8622. automatically initiated in full-screen SAVDMs. 
  8623.  
  8624. In addition, groups of applications which depend on the sharing of global 
  8625. Windows memory will not be able to run in a "seamless" WIN-OS/2 VDM, unless it 
  8626. is possible to manually initiate one application in the set and then have that 
  8627. application programmatically spawn the rest of the applications in the set. In 
  8628. theory, this situation should never occur because the casual sharing of Windows 
  8629. global memory is expressly against the Microsoft guidelines for Windows system 
  8630. programming.  However, if there are applications that depend on such sharing, 
  8631. the user will have to explicitly know to run them in a full-screen MAVDM. 
  8632.  
  8633.  
  8634. ΓòÉΓòÉΓòÉ 18.7. Windows Environment Settings ΓòÉΓòÉΓòÉ
  8635.  
  8636. When Windows application support is selected during installation of OS/2 
  8637. Version 2.0, a WIN.INI file is built.  The options for devices selected for the 
  8638. OS/2 environment are included in this file. 
  8639.  
  8640. Should the user migrate from a DOS/Windows 3.0 environment, the original 
  8641. WIN.INI created by Windows will be left unchanged.  At installation time, the 
  8642. Windows installation process will examine the original AUTOEXEC.BAT file and 
  8643. search in all directories specified in the PATH statement in there for the 
  8644. original Windows WIN.COM file.  If one exists, it will copy all Windows *.INI 
  8645. files and all the Windows application *.INI files from that same subdirectory 
  8646. into the \OS\MDOS\WINOS2 subdirectory.  It will then modify these copies to 
  8647. adjust for the appropriate video, mouse, country and keyboard settings.  This 
  8648. happens in accordance with the answers provided during the initial OS/2 setup. 
  8649.  
  8650. Figure "Migrating the Windows Initialization Files" 
  8651.  
  8652. The Windows group files (*.GRP) and other Windows application-specific *.INI 
  8653. files are also copied.  The modified WIN.INI and PROGMAN.INI files will have 
  8654. their path statements modified to point to the new locations of these files. 
  8655.  
  8656. Printer definitions for the Windows environment will also depend on the OS/2 
  8657. setup, rather than on any previously defined printer device driver.  Of course, 
  8658. all path statements in these files will be modified to point to the appropriate 
  8659. directories. 
  8660.  
  8661. If a user installs OS/2 V2.0 over a previous version of OS/2 V2.0, the Windows 
  8662. install process will look for the existence of \OS2\MDOS\WINOS2\WINOS2.COM. If 
  8663. found, it will perform the same migration process from that base environment. 
  8664. If none of these files can be found, the Windows installation process will 
  8665. start from scratch, in the same way that a first-time Windows 3.0 installation 
  8666. would do it. 
  8667.  
  8668. The following initialization files are created/modified: 
  8669.  
  8670.  WIN.INI 
  8671.  
  8672.  PROGMAN.INI 
  8673.  
  8674.  CONTROL.INI 
  8675.  
  8676.  SYSTEM.INI. 
  8677.  
  8678. The initialization and group files are required to restore a corrupted Windows 
  8679. environment. Backups of these files should be taken prior to making any changes 
  8680. to this environment. 
  8681.  
  8682. These files and their contents are described in the following sections. 
  8683.  
  8684.  
  8685. ΓòÉΓòÉΓòÉ 18.7.1. WIN.INI ΓòÉΓòÉΓòÉ
  8686.  
  8687. WIN.INI contains a number of sections which may be customized by the user, 
  8688. including which applications should be started or run when a Windows MAVDM is 
  8689. started. Each Windows application is recorded in a separate section indicating 
  8690. the drive and path to execute the application. The supported file extensions, 
  8691. for each application installed, are recorded in the Extensions section. 
  8692.  
  8693. Users need to be careful when applying any changes to this file, especially 
  8694. when it comes to configuring of any device drivers.  The user might install a 
  8695. device driver which either does not exist or is not supported under OS/2 V2.0, 
  8696. such as specialized video device drivers. 
  8697.  
  8698. Most, but not all, Windows applications also have their private entries in the 
  8699. WIN.INI file.  Usually, such entries consist merely of a pointer to the 
  8700. application's own working directory.  However, some applications register all 
  8701. their installation-dependent configuration information, and may therefore be 
  8702. very dependent upon finding their data in this file.  The migration process 
  8703. will take care of these entries and migrate them appropriately. 
  8704.  
  8705.  
  8706. ΓòÉΓòÉΓòÉ 18.7.2. PROGMAN.INI ΓòÉΓòÉΓòÉ
  8707.  
  8708. PROGMAN.INI contains the Windows Program Manager settings.  This file contains 
  8709. the following sections: 
  8710.  
  8711.  Setting: Describes the settings of the Program Manager, along with the user's 
  8712.   preferences. 
  8713.  
  8714.  Groups: Specifies the Program Groups that exist in Program Manager and the 
  8715.   path name to their group files (*.GRP). 
  8716.  
  8717.  
  8718. ΓòÉΓòÉΓòÉ 18.7.3. CONTROL.INI ΓòÉΓòÉΓòÉ
  8719.  
  8720. CONTROL.INI contains the color and desktop settings for the Windows Control 
  8721. Panel.  The following options are available: 
  8722.  
  8723.  Current: Specifies the window color setting 
  8724.  
  8725.  Color Schemes: Specifies the available color options 
  8726.  
  8727.  Custom Colors: Specifies up to 16 customization colors 
  8728.  
  8729.  Patterns: Specifies options for the desktop pattern. 
  8730.  
  8731.  
  8732. ΓòÉΓòÉΓòÉ 18.7.4. SYSTEM.INI ΓòÉΓòÉΓòÉ
  8733.  
  8734. SYSTEM.INI contains the global system information used by Windows when it 
  8735. starts. Changes are not effective until Windows is restarted. 
  8736.  
  8737. The following sections are included: 
  8738.  
  8739.  Boot: Lists the drivers and Windows modules. The OS/2 file contains new Boot 
  8740.   section keywords which cover MAVDM and SAVDM default applications: 
  8741.  
  8742.    GOPM      This program returns the user to the Workplace Shell 
  8743.  
  8744.    Clipboard The modified WIN-OS/2 Clipboard View program 
  8745.  
  8746.    DDEAGENT  The WIN-OS/2 DDE (Dynamic Data Exchange) program 
  8747.  
  8748.    Printman  The modified WIN-OS/2 Print Manager program, in MAVDM only. 
  8749.  
  8750.  Boot.description: Lists the names of devices the user can change using 
  8751.   Windows Setup 
  8752.  
  8753.  Keyboard: Contains information about the keyboard 
  8754.  
  8755.  NonWindowsApp: This section should not contain any information, since 
  8756.   non-Windows applications are started from the OS/2 desktop. In the case of a 
  8757.   migrated Windows environment, this section might contain information, but 
  8758.   under OS/2 V2.0 it will be ignored. 
  8759.  
  8760.  Standard: Contains information required by Windows to run in standard mode 
  8761.  
  8762.  386Enh: Contains information used by Windows to operate in 386 enhanced mode. 
  8763.   This section is not used as OS/2 provides equivalent function. 
  8764.  
  8765.  
  8766. ΓòÉΓòÉΓòÉ 18.7.5. DOS and WIN-OS/2 Settings ΓòÉΓòÉΓòÉ
  8767.  
  8768. The following DOS settings are automatically defined for any Windows 
  8769. application under the Workplace Shell. If a user explicitly modifies these 
  8770. entries, following these settings is recommended: 
  8771.  
  8772. WIN_RUNMODE                        AUTO 
  8773.  
  8774.                                    OS/2 V2.0 will decide whether the Windows 
  8775.                                    application will run in real or standard 
  8776.                                    mode, unless the user specifically selects a 
  8777.                                    mode. 
  8778.  
  8779. KBD_CTRL_BYPAS                     CTRL_ESC 
  8780.  
  8781.                                    This keyboard sequence is required in a 
  8782.                                    WIN-OS/2 MAVDM in order to bring up the 
  8783.                                    Windows List.  If not bypassed, the Ctrl+Esc 
  8784.                                    sequence is trapped by the Workplace Shell. 
  8785.  
  8786. MOUSE_EXCLUSIVE_ACCESS             ON 
  8787.  
  8788.                                    Only necessary if the user wishes to run 
  8789.                                    this SAVDM or MAVDM in a window under the 
  8790.                                    Workplace Shell.  Note this pertains to 
  8791.                                    running the entire VDM in a Presentation 
  8792.                                    Manager window, not to running in seamless 
  8793.                                    mode. 
  8794.  
  8795. DPMI_MEMORY_LIMIT                  2 (MB) 
  8796.  
  8797.                                    This is the default for the Windows 
  8798.                                    environment and can always be increased when 
  8799.                                    needed.  However, decreasing this value is 
  8800.                                    not recommended. 
  8801.  
  8802. IDLE_SENSITIVITY                   75 
  8803.  
  8804.                                    This is the default value.  The performance 
  8805.                                    of some Windows applications can be improved 
  8806.                                    by re-adjusting this value to their specific 
  8807.                                    needs.  In particular, applications which 
  8808.                                    make extensive use of the mouse may exhibit 
  8809.                                    "jumpy" mouse movement when IDLE_SENSITIVITY 
  8810.                                    is allowed to default; for such 
  8811.                                    applications, IDLE_SENSITIVITY should be set 
  8812.                                    to 100, which disables idle detection. 
  8813.  
  8814.  
  8815. ΓòÉΓòÉΓòÉ 18.8. Windows Device Drivers ΓòÉΓòÉΓòÉ
  8816.  
  8817. Upon installation, the WIN.INI file is updated with the appropriate information 
  8818. for the following options.  Installation will install the following Windows 
  8819. device drivers in the appropriate directories: 
  8820.  
  8821.  Keyboard 
  8822.  
  8823.  Mouse 
  8824.  
  8825.  Video 
  8826.  
  8827.  Printer 
  8828.  
  8829.  Codepage/country. 
  8830.  
  8831. If a device driver is supported in Windows but not supported by OS/2, the 
  8832. Windows version will not be supported. 
  8833.  
  8834. Note:   Any "illegal" combination of OS/2 and Windows display device drivers 
  8835.         may cause the Windows environment to crash or not to come up at all. 
  8836.  
  8837. On the other hand, the user can configure a useful dual screen configuration, 
  8838. which will actually run the Workplace Shell on one screen and Windows on the 
  8839. other simultaneously.  OS/2 V2.0 may be run with the standard system display, 
  8840. such as VGA, XGA and so on, and in addition, another display adapter may be 
  8841. installed to run Windows applications, such as the IBM PS/2 Image Adapter/A, 
  8842. which is a Micro Channel card and supported on PS/2s. This requires the 
  8843. appropriate Windows display device driver to run exclusively on that adapter 
  8844. and the screen connected to it.  Of course, the user must change several things 
  8845. (examples shown relate to the Image Adapter/A): 
  8846.  
  8847. CONFIG.SYS     Add "DEVICE=C:\MYSUB\IADOSRFS.SYS" 
  8848.  
  8849.                This may be done via the DOS Settings for that particular 
  8850.                Windows session object under the Workplace Shell. 
  8851.  
  8852. SYSTEM.INI     Change "display.drv=IAA.DRV" 
  8853.  
  8854. IASETUP.EXE    This is a DOS program which needs to be run once after 
  8855.                installation.  This utility will actually add some special 
  8856.                entries to the WIN.INI file, which will tell the IAA.DRV display 
  8857.                device driver what resolution and color setup to use on the 
  8858.                Image Adapter. 
  8859.  
  8860. These device drivers and programs can be found on the Image Adapter support 
  8861. diskette. 
  8862.  
  8863. Note:   Do not confuse the scenario above with OS/2's standard dual screen 
  8864.         support, which is installed and configured automatically if a VGA and 
  8865.         8514 (or XGA) are found during initial installation.  In that case, 
  8866.         only one screen will be active at any given moment, while the display 
  8867.         of the other will be frozen. 
  8868.  
  8869.  
  8870. ΓòÉΓòÉΓòÉ 18.9. Print Support for Windows Applications ΓòÉΓòÉΓòÉ
  8871.  
  8872. The installation procedure will update the new WIN.INI file to include the 
  8873. printer device driver details required by Windows for printers selected under 
  8874. OS/2.  Installation selects a Windows printer device driver comparable with the 
  8875. OS/2 printer device driver for that printer. The Windows printer device driver 
  8876. will initially operate in its default mode. If the printer device driver must 
  8877. be configured in a mode other than the default mode, the printer should be 
  8878. configured from within the Windows Control Panel. 
  8879.  
  8880. If there is no equivalent OS/2 printer device driver, the Windows device driver 
  8881. should be installed and configured via the Windows Control panel. The user 
  8882. should also use a printer port which is associated with the IBMNULL.DRV PM 
  8883. printer device driver on the OS/2 side.  This will ensure the print data is 
  8884. passed straight through the port without OS/2's print subsystem modifying 
  8885. anything within the data stream.  Even the usual "printer reset" should not 
  8886. occur. 
  8887.  
  8888.  
  8889. ΓòÉΓòÉΓòÉ 18.9.1. Print Subsystem Architecture ΓòÉΓòÉΓòÉ
  8890.  
  8891. There are some interesting and significant changes to the OS/2 print subsystem 
  8892. architecture which are used to support Windows applications, and which are 
  8893. worth noting: 
  8894.  
  8895.  The print subsystem has been expanded to provide printing support for Windows 
  8896.   applications running on WIN-OS/2. 
  8897.  
  8898.  The OS/2 file system now intercepts ALL print jobs routed to an LPTx port, 
  8899.   even those directed to WIN-OS/2 LPT1 to LPT3 and WIN-OS/2 LPT1.OS2 to 
  8900.   LPT2.OS2 ports, and routes them to the OS/2 spooler. Jobs routed to a COM 
  8901.   port are not intercepted by the file system and can proceed directly to the 
  8902.   physical port via the serial port device driver. 
  8903.  
  8904. Figure "Detailed View of the WIN-OS/2 Data Connections" shows the WIN-OS/2 
  8905. details of the print subsystem architecture in more detail.  The interesting 
  8906. feature to note here is that a second spooler is present; that is, the WIN-OS/2 
  8907. spooler. The WIN-OS/2 spooler is the OS/2 V2.0 implementation of the Windows 
  8908. spooler. Similarly, the WIN-OS/2 Print Manager and WIN-OS/2 Control Panel 
  8909. represent the OS/2 V2.0 implementation of the Windows Print Manager and Windows 
  8910. Control Panel. There are minor user changes apparent in the WIN-OS/2 Control 
  8911. Panel, but these provide extra function rather than take it away. 
  8912.  
  8913. For WIN-OS/2 printing, raw print data is generated via the WIN-OS/2 printer 
  8914. driver and GDI (Graphical Device Interface).  The WIN-OS/2 printer driver 
  8915. directs the data to the appropriate port but the data route then taken varies 
  8916. depending on whether or not the OS/2 spooler is enabled, as shown in Figure 
  8917. "Low Level View of the WIN-OS/2 Printing Data Flow". 
  8918.  
  8919. If the OS/2 spooler is enabled, an INT21 is issued which provides a direct path 
  8920. for the print data to come into the OS/2 V2.0 file system.  Jobs directed to 
  8921. LPTx or LPTx.OS2 ports are intercepted by the file system and are sent on to 
  8922. the SplQmxxx interface. The print data is then processed by the print subsystem 
  8923. as though it was raw data arriving from a PM queued application. Note that for 
  8924. this scenario, the print data is processed by the WIN-OS/2 printer driver and 
  8925. also part 2 of the equivalent OS/2 printer driver. 
  8926.  
  8927. Note:   It is important to ensure that the WIN-OS/2 and OS/2 printer drivers 
  8928.         match to avoid conflict between them. If you use a WIN-OS/2 driver 
  8929.         which has no OS/2 equivalent then use the IBMNULL driver. 
  8930.  
  8931. Print jobs directed to COMx ports are not intercepted by the file system as for 
  8932. LPTx/LPTx.OS2 ports. Instead, they are passed directly to the serial  kernel 
  8933. device driver. 
  8934.  
  8935. If the OS/2 spooler is disabled, the print data bypasses many of the print 
  8936. subsystem components.  In this scenario, the WIN-OS/2 spooler will be called 
  8937. upon to spool the print job, which is actually written to the root directory of 
  8938. the fixed disk.  The queued spool files are distinguished by having the file 
  8939. extension .TMP. If the WIN-OS/2 spooler is also disabled then the print job 
  8940. passes straight through. 
  8941.  
  8942. With the OS/2 spooler disabled, there are three routes that print jobs can 
  8943. take, according to their port destination: 
  8944.  
  8945.  1. When it is the turn of a COMx job to be printed, the WIN-OS/2 spooler 
  8946.     passes the print job to the COM VDD (Virtual Device Driver). The reason for 
  8947.     this is that the job will ultimately be printed through the OS/2 serial KDD 
  8948.     (Kernel Device Driver) which is COM.SYS. A VDD cannot call upon physical 
  8949.     device drivers, such as COM.SYS, directly.  Instead it must call on the 
  8950.     services of the VDH (Virtual Device Helper) which is a programming 
  8951.     interface that is able to do this on behalf of the VDD.  Consequently, the 
  8952.     VDD passes the print data to the serial KDD via the VDH. 
  8953.  
  8954.     Note:   If you are printing to a COMx port, the WIN-OS/2 printer device 
  8955.             driver needs to initialize that port and know about the handshaking 
  8956.             protocol. To specify the correct settings, you will have to use the 
  8957.             WIN-OS/2 Control Panel and click on the Ports icon. 
  8958.  
  8959.     You should also make sure that you have installed the matching PM printer 
  8960.     device driver under the Workplace Shell. If you don't have a matching 
  8961.     version, use the IBMNULL printer device driver. This printer object needs 
  8962.     to be assigned to the same COMx port and the settings must match the 
  8963.     settings on the WIN-OS/2 side as well as the current printer setup. 
  8964.  
  8965.     If you don't do that, the printing result will be unpredictable, especially 
  8966.     for large and complex print jobs. 
  8967.  
  8968.  2. Jobs directed to LPTx are routed to the parallel physical device driver, 
  8969.     PRINT0x.SYS.SYS, via INT21. 
  8970.  
  8971.  3. Jobs sent to LPTx.OS2 are routed directly to the parallel physical device 
  8972.     driver from the WIN-OS/2 spooler. 
  8973.  
  8974. Recommendation:  It is strongly recommended that users operate the print 
  8975.                  subsystem with both spoolers enabled. Otherwise, print data 
  8976.                  from different jobs may become mixed up, and individual 
  8977.                  applications may have to wait until printing is completed 
  8978.                  before resuming execution. 
  8979.  
  8980. For more details about the entire print subsystem, including DOS and WIN-OS/2 
  8981. sessions, readers should refer to OS/2 Version 2.0 - Volume 5:  Print 
  8982. Subsystem. 
  8983.  
  8984.  
  8985. ΓòÉΓòÉΓòÉ 18.10. Font Support ΓòÉΓòÉΓòÉ
  8986.  
  8987. The following discussion can also be found in OS/2 Version 2.0 - Volume 5: 
  8988. Print Subsystem, including more details about Presentation Manager, the 
  8989. Workplace Shell, and the print subsystem. 
  8990.  
  8991. Fonts are used for output by the system to two devices: 
  8992.  
  8993.  1. Displays 
  8994.  
  8995.  2. Printers. 
  8996.  
  8997. With the many types of displays and even more numerous types of printers one 
  8998. can imagine the complexity of tracking who can use which fonts and what do they 
  8999. look like on a 75 dot display as well as a 300 dot printer. 
  9000.  
  9001. OS/2 Version 2.0 utilizes Adobe** Type Manager (ATM) for this specific purpose. 
  9002. There are two ATMs present in OS/2 Version 2.0, one for OS/2 PM applications 
  9003. and the other for WIN-OS/2 applications. These ATMs allow the system to provide 
  9004. a seamless look and consistent output while using most applications. Because 
  9005. there are two ATMs with some duplicate files, however, user installation and 
  9006. management is critical. 
  9007.  
  9008.  
  9009. ΓòÉΓòÉΓòÉ 18.10.1. Adobe Type Manager Overview ΓòÉΓòÉΓòÉ
  9010.  
  9011. ATM provides WYSIWYG text to all OS/2 V2.0 PM and WIN-OS/2 supported printers 
  9012. and displays. WYSIWYG (What You See Is What You Get) implies that what you see 
  9013. on the display is what you will see on the printed page. In reality, a 75 dot 
  9014. per inch display can not show you what a 300 dot per inch printer will produce. 
  9015. It is physically impossible. What it will give you is fully formed characters 
  9016. in virtually any size and a sense of the "balance" of the page with respect to 
  9017. line, word and letter spacing. With ATM you have the ability to install and use 
  9018. any of the hundreds of Type 1 Fonts compatible with the PostScript** Page 
  9019. Description Language. Thirteen Type 1 fonts are included in OS/2 V2.0 in four 
  9020. font groups (Times New**, Helvetica**, Courier and Symbol). This group provides 
  9021. a satisfactory basic working set, to which extra fonts can be added. 
  9022.  
  9023. With ATM, users now have a wider choice of fonts, and can display and print 
  9024. them even on lower-cost devices. For example, PostScript-quality fonts can now 
  9025. be printed on non-PostScript devices such as the IBM 4019 and 4029, and the 
  9026. HP** LaserJet** series without the need to add the additional PostScript 
  9027. interpreter option. You still get excellent results, though slower performance, 
  9028. as the fonts will be rasterized in the PS/2 rather than the printer. Even an 
  9029. IBM 4201 or an IBM 5152 or other low-cost matrix printers can print Type 1 
  9030. fonts but, of course, not with the same quality as laser printers. These same 
  9031. fonts can also be "installed" as downloadable fonts to be sent to PostScript 
  9032. printers for faster print performance. 
  9033.  
  9034. The list of available fonts for most applications is a combination of the list 
  9035. in the printer device driver you have selected for output and the fonts you 
  9036. have installed in the ATMs. Tests with Lotus 1-2-3 for Windows, Aldus** 
  9037. PageMaker, and DeScribe** indicated that as soon as additional fonts were 
  9038. installed in the Font Palette of OS/2 PM and the ATM Control Panel of WIN-OS/2, 
  9039. all of these applications were able to include them in their font choice list, 
  9040. display them and print them. Some applications like CorelDraw!** 2.0 and 
  9041. Micrographx** Designer use their own internal outline format for fonts. They 
  9042. will use the same Type 1 fonts as ATM but the fonts must be installed 
  9043. seperately in each application. Consult your application documentation to 
  9044. determine how each one handles fonts. 
  9045.  
  9046.  
  9047. ΓòÉΓòÉΓòÉ 18.10.2. ATM File Formats ΓòÉΓòÉΓòÉ
  9048.  
  9049. Files: .FON 
  9050.  
  9051. These files hold the standard OS/2 V2.0 bitmap fonts and are copied there by 
  9052. the OS/2 V2.0 install procedure. 
  9053.  
  9054. Files: .PSF 
  9055.  
  9056. PostScript font files are the new Type 1 Font files in internal-to-PM format 
  9057. which is designed (for efficiency) for the core fonts only (Times New, Courier 
  9058. and Helvetica). 
  9059.  
  9060. Files: .AFM 
  9061.  
  9062. These files hold the Adobe Font Metrics and are used by OS/2 PM ATM. 
  9063. Information such as character widths and kerning pairs are in this file. 
  9064.  
  9065. Files: .PFB 
  9066.  
  9067. These files hold the Printer Font Binary and are used by both OS/2 PM ATM and 
  9068. WIN-OS/2 ATM. These are the files that can be downloaded into printer storage. 
  9069.  
  9070. Files: .PFM 
  9071.  
  9072. These files hold the Printer Font Metrics and are used by the PostScript device 
  9073. driver to download fonts and by WIN-OS/2 ATM. 
  9074.  
  9075. Files: .PFA 
  9076.  
  9077. These files hold the Printer Font ASCII and are embedded by the PostScript 
  9078. device driver into the PostScript print job if you installed them as 
  9079. downloadable fonts. 
  9080.  
  9081. For non-ATM file formats, such as the native formats for PCL, PPDS and 420X 
  9082. printers. 
  9083.  
  9084. Figure "File Structure of Adobe Type Manager" 
  9085.  
  9086.  
  9087. ΓòÉΓòÉΓòÉ 18.11. ATM for WIN-OS/2 ΓòÉΓòÉΓòÉ
  9088.  
  9089. While ATM for OS/2 PM is integrated into the operating system, ATM for WIN-OS/2 
  9090. is a separate program that is automatically installed into the WIN-OS/2 desktop 
  9091. for you. ATM for WIN-OS/2 is accessed by using the ATM Control Panel in the 
  9092. WIN-OS/2 Main group. If you plan to manage fonts frequently after your initial 
  9093. installation it is recommended that you create a program icon on your OS/2 PM 
  9094. desktop for the WIN-OS/2 ATM control panel. The next section will describe how 
  9095. to do this. 
  9096.  
  9097.  
  9098. ΓòÉΓòÉΓòÉ 18.11.1. Installing ATM for WIN-OS/2 ΓòÉΓòÉΓòÉ
  9099.  
  9100. ATM for WIN-OS/2 is automatically installed when you install the OS/2 base 
  9101. code. However, the 13 "IBM Core Fonts" that are automatically installed for you 
  9102. in OS/2 PM are not installed under WIN-OS/2. In fact ATM for WIN-OS/2 is itself 
  9103. not active until you install at least one font. This is why you will see an "X" 
  9104. over the ATM icon when you start the WIN-OS/2 Full-Screen command prompt if you 
  9105. have not installed any fonts. Included on the device drivers diskettes are the 
  9106. necessary font files to install these "IBM Core Fonts" for WIN-OS/2. They are 
  9107. currently located on device driver diskette #5. 
  9108.  
  9109. As mentioned previously, it is a good idea to have the WIN-OS/2 ATM icon on 
  9110. your OS2 PM desktop if you manage fonts frequently. There are two ways to do 
  9111. this: 
  9112.  
  9113.  1. You can use the Migrate Applications program in the System Setup folder. 
  9114.     However, this action will place the icon in a folder called "Additional 
  9115.     Windows Programs". You will then have to open that folder and drag-and-drop 
  9116.     the ATM Control Panel icon onto your desktop. 
  9117.  
  9118.  2. You can also open the Templates folder and drag-and-drop the Program icon 
  9119.     on your desktop and type in the prompts. ATM for WIN-OS/2 is located in 
  9120.     \OS2\MDOS\WINOS2\ATMCNTRL.EXE. Use \OS2\MDOS\WINOS2 as your working 
  9121.     directory. Under Session select WIN-OS/2 window if available, otherwise 
  9122.     select WIN-OS/2 full screen. 
  9123.  
  9124. Under certain conditions ATM may become disabled or you may want to remove it 
  9125. for performance reasons if you only use standard fonts. In either case ATM for 
  9126. WIN-OS/2 is activated based on entries in the SYSTEM.INI file located in the 
  9127. path \OS2\MDOS\WINOS2. If installed correctly you will see the following 
  9128. statements: 
  9129.  
  9130.  1. system.drv=atmsys.drv 
  9131.  
  9132.  2. atm.system.drv=system.drv 
  9133.  
  9134. To disable ATM: 
  9135.  
  9136.  1. Delete the atm.system.drv=system.drv statement 
  9137.  
  9138.  2. Change system.drv=atmsysdrv to system.drv=system.drv. 
  9139.  
  9140.  
  9141. ΓòÉΓòÉΓòÉ 18.11.2. Installing Additional Fonts for WIN-OS/2 ATM ΓòÉΓòÉΓòÉ
  9142.  
  9143. Before installing any additional fonts for WIN-OS/2 make sure that all of your 
  9144. printers are installed and that they are configured for the correct output 
  9145. port. WIN-OS/2 maintains its font information in the ATM.INI for non-PostScript 
  9146. printers and in the WIN.INI for PostScript printers. For PostScript printers 
  9147. this means that PostScript printers installed after the font installation will 
  9148. not have those fonts in their list. Also if you change the output port of an 
  9149. installed PostScript printer then your fonts will disappear unless the new port 
  9150. also had a PostScript printer assigned to it while the fonts were being 
  9151. installed. 
  9152.  
  9153. To install an additional font: 
  9154.  
  9155.  1. Open the ATM Control Panel 
  9156.  
  9157.  2. Click on Add... 
  9158.  
  9159.  3. Double Click on the source of the new font(s) 
  9160.  
  9161.  4. Click on the Font files you wish to add 
  9162.  
  9163.  5. Click on Add 
  9164.  
  9165.  6. Click on Exit 
  9166.  
  9167. You must restart Windows to access the new fonts. The system will prompt you to 
  9168. do this. 
  9169.  
  9170. Important:  When you install the fonts the system will prompt you with 
  9171.             suggested paths for the files. Although you may change the path, 
  9172.             remember one thing: OS2 PM ATM will be installing the .PFB file as 
  9173.             well and will place it in a different directory. You will be 
  9174.             tempted to use the same directory for both OS/2 PM and WIN-OS/2. We 
  9175.             recommend that you use the default settings because when you delete 
  9176.             a font with the OS/2 PM Font Palette it will also delete the .PFB 
  9177.             font file! This will make the font unusable, although still 
  9178.             installed, in WIN-OS/2. Allowing the system to keep your OS/2 PM 
  9179.             and WIN-OS/2 fonts separate will save a lot of confusion in 
  9180.             managing fonts. 
  9181.  
  9182. These files would have been added to the \PSFONTS directory after installing 
  9183. the Berthold Bodoni Antiqua fonts. 
  9184.  
  9185. \PSFONTS. 
  9186.  
  9187.                       5-01-90   8:00a     39648           0  bpbi____.pfb
  9188.                       5-01-90   8:00a     38664           0  bpb_____.pfb
  9189.                       5-01-90   8:00a     36930           0  bpi_____.pfb
  9190.                       5-01-90   8:00a     37381           0  bpli____.pfb
  9191.                       5-01-90   8:00a     35979           0  bpl_____.pfb
  9192.                       5-01-90   8:00a     38740           0  bpmi____.pfb
  9193.                       5-01-90   8:00a     38098           0  bpm_____.pfb
  9194.                       5-01-90   8:00a     35837           0  bprg____.pfb
  9195.  
  9196. And these files would have been added to the \PSFONTS\PFM directory after 
  9197. installing the Berthold Bodoni Antiqua fonts. 
  9198.  
  9199. \PSFONTS\PFM. 
  9200.  
  9201.                               4-10-92  10:42a      7016           0  BPBI____.PFM
  9202.                               4-10-92  10:42a      5830           0  BPB_____.PFM
  9203.                               4-10-92  10:43a      6019           0  BPI_____.PFM
  9204.                               4-10-92  10:43a      5934           0  BPLI____.PFM
  9205.                               4-10-92  10:42a      5700           0  BPL_____.PFM
  9206.                               4-10-92  10:43a      7869           0  BPMI____.PFM
  9207.                               4-10-92  10:43a      5571           0  BPM_____.PFM
  9208.                               4-10-92  10:43a      6004           0  BPRG____.PFM
  9209.  
  9210. Note:   The internal file format is different from the standard core fonts 
  9211. delivered with OS/2 V2.0. Those have been modified for performance reasons, 
  9212. where these fonts are installed as standard Type 1 fonts. :enote. 
  9213.  
  9214. Important:  As information is added to the ATM.INI file, don't try to install 
  9215.             or remove fonts just by copying or erasing files. Adding or 
  9216.             deleting fonts must be done with the ATM Control Panel and/or the 
  9217.             Print Manager. 
  9218.  
  9219. For faster performance and better typeset quality don't forget to either 
  9220. install these fonts as downloadable, or download them directly, if you are 
  9221. using them with a PostScript printer, which does not have them already 
  9222. built-in. 
  9223.  
  9224.  
  9225. ΓòÉΓòÉΓòÉ 18.11.3. Deleting Fonts for WIN-OS/2 ATM ΓòÉΓòÉΓòÉ
  9226.  
  9227. The standard core fonts and the additional Type 1 fonts have to be deleted with 
  9228. the ATM Control Panel. To delete them: 
  9229.  
  9230.  1. Open the ATM Control Panel 
  9231.  
  9232.  2. Click on the font(s) to be removed 
  9233.  
  9234.  3. Click on Remove 
  9235.  
  9236.  4. Click on Yes in the confirmation box 
  9237.  
  9238.  5. Click on Exit 
  9239.  
  9240. You must restart Windows to use the updated font list in the ATM.INI file. The 
  9241. system will prompt you to do this. The soft font entries in the WIN.INI file, 
  9242. however, will not be deleted. This means that you will still "see" the deleted 
  9243. fonts in the font list for your applications if you choose a printer(usually 
  9244. PostScript) that has these entries. Although the font name will appear, when 
  9245. you select it you will not get the expected screen font as it has been deleted 
  9246. from ATM. Instead you will get an installed font, usually Times or Helv, 
  9247. depending on the font you selected. 
  9248.  
  9249. In order to remove the deleted fonts from the lists you must edit the 
  9250. \OS2\MDOS\WINOS2\WIN.INI file. The following example shows you a before and 
  9251. after version of the WIN.INI file if you wanted to remove all Berthold Bodoni 
  9252. Antiqua fonts from your application font lists. 
  9253.  
  9254. WIN.INI after ATM delete but before manual edit. 
  9255.  
  9256. [PostScript,LPT2.OS2]
  9257. device=36
  9258. feed1=1
  9259. feed3=1
  9260. feed5=1
  9261. feed15=1
  9262. softfonts=12
  9263. softfont1=c:\psfonts\pfm\archi___.pfm,c:\psfonts\archi___.pfb
  9264. softfont2=c:\psfonts\pfm\balleeng.pfm,c:\psfonts\balleeng.pfb
  9265. softfont3=c:\psfonts\pfm\bpb_____.pfm,c:\psfonts\bpb_____.pfb
  9266. softfont4=c:\psfonts\pfm\bpbi____.pfm,c:\psfonts\bpbi____.pfb
  9267. softfont5=c:\psfonts\pfm\bpl_____.pfm,c:\psfonts\bpl_____.pfb
  9268. softfont6=c:\psfonts\pfm\bpli____.pfm,c:\psfonts\bpli____.pfb
  9269. softfont7=c:\psfonts\pfm\bprg____.pfm,c:\psfonts\bprg____.pfb
  9270. softfont8=c:\psfonts\pfm\bpm_____.pfm,c:\psfonts\bpm_____.pfb
  9271. softfont9=c:\psfonts\pfm\bpmi____.pfm,c:\psfonts\bpmi____.pfb
  9272. softfont10=c:\psfonts\pfm\bpi_____.pfm,c:\psfonts\bpi_____.pfb
  9273. softfont11=c:\psfonts\pfm\blackcha.pfm,c:\psfonts\blackcha.pfb
  9274. softfont12=c:\psfonts\pfm\saintfra.pfm,c:\psfonts\saintfra.pfb
  9275.  
  9276. WIN.INI after manual edit. 
  9277.  
  9278. [PostScript,LPT2.OS2]
  9279. device=36
  9280. feed1=1
  9281. feed3=1
  9282. feed5=1
  9283. feed15=1
  9284. softfonts=4
  9285. softfont1=c:\psfonts\pfm\archi___.pfm,c:\psfonts\archi___.pfb
  9286. softfont2=c:\psfonts\pfm\balleeng.pfm,c:\psfonts\balleeng.pfb
  9287. softfont3=c:\psfonts\pfm\blackcha.pfm,c:\psfonts\blackcha.pfb
  9288. softfont4=c:\psfonts\pfm\saintfra.pfm,c:\psfonts\saintfra.pfb
  9289.  
  9290. Note:   In addition to deleting the line entries you must also renumber the 
  9291. remaining lines and edit the total number in the softfonts= statement. If you 
  9292. have more than one printer installed you may have to edit other groups in the 
  9293. WIN.INI under other port entries. 
  9294.  
  9295.  
  9296. ΓòÉΓòÉΓòÉ 18.12. Clipboard Support ΓòÉΓòÉΓòÉ
  9297.  
  9298. OS/2 Version 2.0 provides clipboard support between Windows applications, in 
  9299. the same or separate VDMs, as well as support between Windows applications and 
  9300. OS/2 Presentation Manager applications.  The clipboard serves as a 
  9301. data-exchange feature acting as a common area to store data handles through 
  9302. which applications exchange formatted data. The same data may be represented in 
  9303. a number of different formats as specified by the application. Note that 
  9304. objects in the clipboard may be of any size and format. 
  9305.  
  9306. The combined OS/2 and Windows clipboard environment under OS/2 Version 2.0 is 
  9307. shown in Figure "OS/2 Version 2.0 Clipboard Environment". 
  9308.  
  9309. Data is formatted in either a predefined or private format, before being copied 
  9310. to the clipboard. In most cases the data is copied to pre-allocated global 
  9311. memory and a function call is used to copy the memory handle to the clipboard. 
  9312. Windows provides a number of predefined data formats: 
  9313.  
  9314. TEXT        Null-terminated text 
  9315.  
  9316. OEMTEXT     Null-terminated text using an OEM character set 
  9317.  
  9318. PICTURE     Metafile picture structure 
  9319.  
  9320. BITMAP      Device-dependent bitmap 
  9321.  
  9322. DIB BITMAP  Device-independent bitmap 
  9323.  
  9324. SYLK        SYLK Standard data interchange format 
  9325.  
  9326. DIF         DIF standard data interchange format. 
  9327.  
  9328. TIFF        Tag Image File Format 
  9329.  
  9330. Any Private Format Will be kept in the same format.  This will be usable only 
  9331.             by applications which know about this private format. 
  9332.  
  9333. These formats will be recognized and exported/imported by the global clipboard 
  9334. server. 
  9335.  
  9336. Data formats which are not supported by the clipboard server, cannot be 
  9337. transferred.  Such formats can only be handled by the local clipboards. This 
  9338. means that such formats may only be used to exchange data between Presentation 
  9339. Manager applications, or between Windows applications running in the same VDM. 
  9340. In addition, some of the data formats will also be converted, because of 
  9341. several differences between Windows and Presentation Manager data structures. 
  9342. This is further discussed in WIN-OS/2 Clipboard Support (Scenario 3 - Cut/Paste 
  9343. Between OS/2 And WIN-OS/2). 
  9344.  
  9345. The OwnerDraw feature in the Windows clipboard is only supported within a 
  9346. MAVDM, as shared memory is required. OwnerDraw is a process whereby a Windows 
  9347. application takes control over the appearance of menu items and has 
  9348. responsibility for managing these menu items. 
  9349.  
  9350. The native Microsoft Windows 3.0 clipboard provides support for both Windows 
  9351. applications and non-Windows applications. Non-Windows applications (that is, 
  9352. "native" DOS applications) run in either full-screen or "windowed" mode.  This 
  9353. kind of environment is not supported in a MAVDM, because it is supported by the 
  9354. Workplace Shell  directly.  Therefore, clipboard support for native DOS 
  9355. applications is provided through Presentation Manager. 
  9356.  
  9357. Should the user wish to capture the contents of a VDM running in full-screen 
  9358. mode, the following approach is adopted: 
  9359.  
  9360.  1. Switch to the Presentation Manager screen containing the VDM 
  9361.  
  9362.  2. Select the System menu on the VDM icon 
  9363.  
  9364.  3. Select Copy All. 
  9365.  
  9366. This procedure will copy the VDM's video buffer to the Presentation Manager 
  9367. clipboard (either in ASCII format or as a Presentation Manager bitmap). 
  9368.  
  9369. Selective copy is available in windowed mode.  When a VDM is running in a 
  9370. window, the user may mark a specific rectangular area which will then be copied 
  9371. into the clipboard. 
  9372.  
  9373. This level of clipboard data exchange is fully supported by the VDM itself. The 
  9374. Windows kernel is not involved at all. 
  9375.  
  9376.  
  9377. ΓòÉΓòÉΓòÉ 18.12.1. WIN-OS/2 Clipboard Support ΓòÉΓòÉΓòÉ
  9378.  
  9379. The WIN-OS/2 clipboard view utility will display the captured data in a number 
  9380. of formats, either predefined or private. Auto displays the data in the format 
  9381. it had when placed onto the clipboard. 
  9382.  
  9383. The clipboard view program CLIPWOS2.EXE, installed in C:\OS2\MDOS\WINOS2, is 
  9384. available within each SAVDM and MAVDM by default.  This is a modified version 
  9385. of the original Windows 3.0 clipboard program. 
  9386.  
  9387. A Clipboard Server (Global Clipboard) runs as a protected mode background 
  9388. process under OS/2 Version 2.0, to service clipboard functions between VDMs. 
  9389. If the Clipboard Server is not executing, clipboard functions are limited to 
  9390. within a single VDM. The Clipboard Server (\OS2\MDOS\WINOS2\VDMSRVR.EXE) is 
  9391. automatically started with the first WIN-OS/2 VDM. 
  9392.  
  9393. Should a user elect to exit from the Windows clipboard, a warning message will 
  9394. be displayed, advising that exiting will terminate public clipboard functions. 
  9395. The clipboard functions within each VDM are public by default, unless 
  9396. explicitly set to LOCAL, which restricts clipboard activity to that WIN-OS/2 
  9397. session only. 
  9398.  
  9399. The WIN-OS/2 clipboard viewer pull-down menus have been enhanced to include 
  9400. support for an Options menu, which contains the Public Clipboard option. 
  9401. Selecting this option causes changes to the local clipboard to be reflected in 
  9402. the public clipboard and vice versa. When deselected, the contents of the 
  9403. public and local clipboards will not affect each other. 
  9404.  
  9405. The File pull-down menu now supports Import/Export functions; Public must be 
  9406. deselected from the Options pull-down menu before Import/Export can be 
  9407. selected. 
  9408.  
  9409. Export will copy the current contents of the local clipboard to the Public 
  9410. clipboard. 
  9411.  
  9412. Import will copy the contents of the public clipboard to the Local clipboard. 
  9413.  
  9414. Implementation Notes:  The Import/Export functions communicate via named pipes 
  9415.                        to the \pipe\CLPAgent to the clipboard program 
  9416.                        (CLIPWOS2.EXE) within each VDM. This could cause 
  9417.                        performance problems on systems which already utilize 
  9418.                        named pipes heavily for other purposes or when the 
  9419.                        content of the clipboard data is too big, for example 
  9420.                        huge bitmaps.  If you don't need to exchange clipboard 
  9421.                        data outside a MAVDM, you could keep it local and 
  9422.                        therefore get around any possible performance problems. 
  9423.  
  9424.  
  9425. ΓòÉΓòÉΓòÉ 18.12.2. Using Cut and Paste ΓòÉΓòÉΓòÉ
  9426.  
  9427. The following three scenarios describe the clipboard functions: 
  9428.  
  9429.  1. Cut and Paste from a Windows Application in a VDM to another application in 
  9430.     a separate VDM; Public is deselected. 
  9431.  
  9432.  2. Cut and Paste between two Windows applications within the same VDM (MAVDM). 
  9433.  
  9434.  3. Cut and Paste between the OS/2 and Windows environments. Cut and Paste 
  9435.     within the OS/2 environment remains essentially unchanged. 
  9436.  
  9437. Scenario 1 - Cut/Paste Between Independent WIN-OS/2 Sessions 
  9438.  
  9439.  1. Cut the data into the local Windows VDM clipboard. 
  9440.  
  9441.  2. Select Export from the clipboard pull-down menu. The data is copied into 
  9442.     the external clipboard. 
  9443.  
  9444.  3. Select the VDM containing the destination Windows application. 
  9445.  
  9446.  4. Select Import from the clipboard pull-down menu. The data is copied from 
  9447.     the external clipboard into the local clipboard of the receiving VDM. 
  9448.  
  9449.  5. Paste the data into the destination Windows application. 
  9450.  
  9451. Note:   Steps 2 and 4 above are not necessary if the clipboard is public in the 
  9452. source and destination VDM. 
  9453.  
  9454. Scenario 2 - Cut/Paste Within A MAVDM 
  9455.  
  9456.  1. Cut the data into the Windows VDM clipboard 
  9457.  
  9458.  2. Paste the data from the clipboard into the destination application. 
  9459.  
  9460. Scenario 3 - Cut/Paste Between OS/2 And WIN-OS/2 
  9461.  
  9462. The OS/2 V2.0 clipboard is activated upon loading the operating system.  A new 
  9463. OS/2 utility named CLIPVIEW.EXE is located in the OS2\APPS\ directory, and has 
  9464. been provided to support the extended clipboard functions. CLIPVIEW.EXE must be 
  9465. started in order to view and transfer the contents of the OS/2 V2.0 clipboard. 
  9466.  
  9467. With the exception of the File option of the Windows clipboard, the same 
  9468. pull-down menus are provided. The Render option is the same as the Display 
  9469. option in the Windows clipboard.  Render will display the contents of the 
  9470. clipboard in a number of different formats.  Because the contents of the 
  9471. clipboard are stored in separate areas in memory, it is possible to view both 
  9472. the ASCII (text) and graphics contents of the clipboard. 
  9473.  
  9474. Note:   An application may or may not clear the entire contents of the 
  9475.         clipboard, prior to copying data to it.  For example, the system editor 
  9476.         will always erase the entire Presentation Manager clipboard, and 
  9477.         therefore any public Windows clipboard as well, before it copies its 
  9478.         text data into it.  On the other hand, some of the Presentation Manager 
  9479.         applications do not behave that way. They will only override the 
  9480.         specific data areas which are copied into the clipboard and leave the 
  9481.         other ones in the clipboard unchanged. 
  9482.  
  9483. The global Windows VDM clipboard is visible to the Presentation Manager 
  9484. clipboard. CLIPVIEW.EXE has been enhanced to perform the following two 
  9485. activities: 
  9486.  
  9487.  1. Update the Presentation Manager clipboard when changes are made to the 
  9488.     global VDM Clipboard 
  9489.  
  9490.  2. Update the global Windows VDM clipboard when changes are made to the 
  9491.     Presentation Manager clipboard. 
  9492.  
  9493. The Presentation Manager clipboard server application is registered as 
  9494. "clipboard viewer" to receive notification of clipboard updates.  This ensures 
  9495. that the following messages are forwarded to the clipboard server, so that when 
  9496. updates are made to the Presentation Manager clipboard, messages are sent to 
  9497. the Presentation Manager CLIPVIEW.EXE. 
  9498.  
  9499.  WM_DESTROYCLIPBOARD: Signals that the contents of the clipboard are being 
  9500.   destroyed 
  9501.  
  9502.  WM_DRAWCLIPBOARD: Signals an application to notify the next application in 
  9503.   the chain of a change to the clipboard 
  9504.  
  9505.  WM_HSCROLLCLIPBOARD: Requests horizontal scrolling of the clipboard contents 
  9506.  
  9507.  WM_PAINTCLIPBOARD: Requests painting of the contents of the clipboard 
  9508.  
  9509.  WM_RENDERALLFMTS: Notifies the owner of the clipboard that it must render 
  9510.   clipboard data in all possible formats 
  9511.  
  9512.  WM-RENDERFMT: Notifies the clipboard owner that it must format the last data 
  9513.   copied to the clipboard 
  9514.  
  9515.  WM_SIZECLIPBOARD: Notifies the clipboard  owner that the clipboard 
  9516.   application's window size has changed 
  9517.  
  9518.  WM_VSCROLLCLIPBOARD: Requests vertical scrolling of the clipboard contents. 
  9519.  
  9520. Note:   No changes have been made to the Presentation Manager API functions to 
  9521.         accommodate this design.  Presentation Manager applications will not 
  9522.         notice any difference; there appears to be just one (Presentation 
  9523.         Manager) clipboard as it always used to be.  The same is true for 
  9524.         Windows applications as well. 
  9525.  
  9526. Data formats are translated from Presentation Manager to Windows formats and 
  9527. vice versa, as required. This translation is performed when data is placed in 
  9528. the global clipboard. The following data formats will be translated between 
  9529. Presentation Manager and Windows: 
  9530.  
  9531. Windows DIB bitmaps: The Windows device-independent bitmaps are translated 
  9532.                      to/from OS/2 Presentation Manager bitmaps. 
  9533.  
  9534. Windows bitmaps:     This translated pre-Windows 3.0 formatted bitmaps to OS/2 
  9535.                      Presentation Manager bitmaps. 
  9536.  
  9537.                      Note:   This is a one way only translation. 
  9538.  
  9539. Windows Metafiles:   Windows metafiles are first internally converted to the 
  9540.                      Windows DIB format by the Windows clipboard viewer, before 
  9541.                      being forwarded to the global clipboard. 
  9542.  
  9543. PM Metafiles:        PM metafiles are first internally converted to the PM 
  9544.                      bitmap format by the PM clipboard viewer, before being 
  9545.                      forwarded to the global clipboard. 
  9546.  
  9547. Text:                ASCII text will be translated in both directions.  If the 
  9548.                      sending and receiving environment are using a different 
  9549.                      codepage, the appropriate codepage translation will take 
  9550.                      place. 
  9551.  
  9552.  
  9553. ΓòÉΓòÉΓòÉ 18.13. Dynamic Data Exchange ΓòÉΓòÉΓòÉ
  9554.  
  9555. This section describes Dynamic Data Exchange (DDE) support between Windows 
  9556. applications in a full-screen VDM. 
  9557.  
  9558.  
  9559. ΓòÉΓòÉΓòÉ 18.13.1. DDE Concepts ΓòÉΓòÉΓòÉ
  9560.  
  9561. DDE is a message protocol for dynamic data exchange between Windows programs. 
  9562. Data may be shared among applications, the intention being to create an 
  9563. integrated Windows environment. 
  9564.  
  9565. Client, Server and Conversation: 
  9566.  
  9567. Two applications participating in dynamic data exchange are said to be engaged 
  9568. in a DDE conversation. The application which initiates the conversation is the 
  9569. client application. The application which responds to the client is the server 
  9570. application.  An application may be engaged in several conversations at the 
  9571. same time, acting as a client in some conversations and as a server in others. 
  9572.  
  9573. A DDE conversation takes place between two windows, one for each of the 
  9574. participating applications.  The window may be the main window of the 
  9575. application, a secondary window associated with the application, or a hidden 
  9576. window. A hidden window is typically used to process DDE messages. 
  9577.  
  9578. DDE identifies the units of data passed between the client and server with a 
  9579. three-level hierarchy of: 
  9580.  
  9581.  Application name 
  9582.  
  9583.  Topic 
  9584.  
  9585.  Item. 
  9586.  
  9587. Each DDE conversation is uniquely identified by the application name and topic. 
  9588. The application name is normally the name of the server application. The topic 
  9589. is a general classification of data, within which multiple data items may be 
  9590. exchanged during the conversation. The item is the actual information related 
  9591. to the conversation topic that is exchanged between the applications.  Values 
  9592. for the data item can be passed from the server to the client, or from client 
  9593. to server. The format of the data item may be any one of the clipboard formats 
  9594. (see Clipboard Support). 
  9595.  
  9596. Once a DDE conversation has been initiated, the client may establish one or 
  9597. more permanent data links with a server. A data link is a communication 
  9598. mechanism by which the server notifies the client whenever the value of a given 
  9599. data item changes.  The link is permanent in the sense that the notification 
  9600. process continues until the data link or DDE conversation is terminated. 
  9601.  
  9602. The DDE link may be warm or hot. In a warm data link, the server notifies the 
  9603. client that a value of a given data item has changed, but the server does not 
  9604. actually send the data value to the client until the client requests it. In a 
  9605. hot data link, the server immediately sends the changed data value to the 
  9606. client. 
  9607.  
  9608. Applications which support DDE typically provide a Copy/Paste command in the 
  9609. Edit menu to allow the user to establish a DDE link. 
  9610.  
  9611.  
  9612. ΓòÉΓòÉΓòÉ 18.13.2. Windows Application to Windows Application ΓòÉΓòÉΓòÉ
  9613.  
  9614. In a native Windows 3.0 environment, a Windows application (client) will 
  9615. broadcast a DDE Initiate message. Windows serially posts a message to every 
  9616. Windows application currently running and then awaits a reply. As described 
  9617. above, the Initiate Conversation message contains the DDE topic to which any 
  9618. Windows application can respond. The client application continues execution 
  9619. when all other applications have serviced the message. At this time, the client 
  9620. application communicates directly with the server applications, as opposed to 
  9621. the initial broadcast message. 
  9622.  
  9623. OS/2 Version 2.0 provides two applications to support communications between 
  9624. VDMs, without altering the Windows code: 
  9625.  
  9626.  A resident Windows application referred to as the DDE ServerAgent (SA) 
  9627.  
  9628.  A DOS protected mode application referred to as the DDEServer (VDMSRVR.EXE). 
  9629. ServerAgent 
  9630.  
  9631. The Windows VDM's resident ServerAgent consists of two parts: 
  9632.  
  9633.  A "ServerAgent" which sends and receives messages outside of the VDM 
  9634.  
  9635.  One or more "agents" (each agent is a child window of the ServerAgent), which 
  9636.   act as "clones" of applications running in other VDMs. 
  9637.  
  9638. If either the DDEServer or the VDM's ServerAgent is not executing, DDE is not 
  9639. available outside of the VDM.  The ServerAgent is automatically started when 
  9640. the Windows VDM is started.  When started, DDE is in public mode.  To keep it 
  9641. local, simply kill (close) the DDE Interchange Agent.  To make it public again, 
  9642. simply start the Interchange Agent once more. 
  9643.  
  9644. Should the user choose to kill the DDE Interchange Agent, an information 
  9645. message will be displayed indicating that DDE activity will be visible only to 
  9646. the Windows applications executing in the current VDM, discontinuing DDE 
  9647. communication with Presentation Manager applications and other Windows 
  9648. applications. 
  9649.  
  9650. The ServerAgent is responsible for all routing of DDE messages, including 
  9651. broadcast messages beyond the confines of the VDM to the DDEServer. The 
  9652. ServerAgent communicates with the DDEServer (VDMSRVR.EXE) via named pipes. 
  9653.  
  9654. Agent applications communicate with Windows applications in their VDM and the 
  9655. ServerAgent executing in their VDM. Only the ServerAgent uses named pipes. 
  9656. Agents send requests to the ServerAgent to be forwarded outside of the VDM. 
  9657.  
  9658. DDEServer (VDMSRVR.EXE) 
  9659.  
  9660. The DDEServer is responsible for routing requests from ServerAgents to the 
  9661. appropriate VDMs. The DDE process is schematically represented in Figure "DDE 
  9662. Process between Windows Environments". 
  9663.  
  9664. The sequence of events for DDE communication between applications running in 
  9665. different WIN-OS/2 VDMs is as follows: 
  9666.  
  9667.  1. A DDE Initiate message is broadcast from Windows application A. 
  9668.  
  9669.  2. The message is forwarded by the ServerAgent to the DDEServer. 
  9670.  
  9671.  3. The DDEServer forwards this message to all other DDEAgents. 
  9672.  
  9673.  4. Each DDEAgent broadcasts this initiate message to all Windows applications 
  9674.     in their VDM. 
  9675.  
  9676.  5. Windows application D responds  affirmatively to this DDE initiate message. 
  9677.  
  9678.  6. The DDEAgent creates a child task ServerAgent A to act as an agent to 
  9679.     Windows application A. 
  9680.  
  9681.  7. The DDEAgent forwards an acknowledgement to the DDEServer. 
  9682.  
  9683.  8. The DDEServer forwards this acknowledgement to the DDEAgent for the Windows 
  9684.     application A. 
  9685.  
  9686.  9. This DDEAgent creates a child task ServerAgent D to act as an agent to 
  9687.     Windows application D. 
  9688.  
  9689. 10. The DDEAgent forwards the response from Windows application D to the 
  9690.     Windows application A. 
  9691.  
  9692. From here on, the two Windows applications communicate through this established 
  9693. path. 
  9694.  
  9695. Appl. A <-> DDEChildAgent D <-> DDEAgent A <-> DDEServer <-> DDEAgent D <-> 
  9696. DDEChildAgent A <-> Appl. D. 
  9697.  
  9698. This mechanism isolates all named pipe transactions (Steps 2, 3, 7 and 8) to 
  9699. the DDEAgents and the DDEServer.  It also gives the Windows application A the 
  9700. illusion of a point-to-point connection to Windows application D (because it 
  9701. will actually communicate with Windows application D's child agent in the same 
  9702. VDM). 
  9703.  
  9704. The interprocess communication protocol used between the Windows applications 
  9705. and the DDEAgents is the original and unmodified DDE protocol. 
  9706.  
  9707. If two Windows applications require significant amounts of DDE, these 
  9708. applications should be executed from within the same MAVDM.  In such instances, 
  9709. the ServerAgent and DDEServer applications would not be required, thereby 
  9710. improving performance and usability.  Once this is done, the user need only 
  9711. kill (close) the participating DDE Interchange Agent to ensure that all DDE 
  9712. messaging is kept local. 
  9713.  
  9714.  
  9715. ΓòÉΓòÉΓòÉ 18.13.3. Windows Application to Presentation Manager Application ΓòÉΓòÉΓòÉ
  9716.  
  9717. DDE support between Windows applications and Presentation Manager applications 
  9718. requires that the DDEServer be linked with the Presentation Manager DDE APIs. 
  9719. Both DDE messages and data formats are translated during the data exchange 
  9720. between Presentation Manager and any given VDM running a Windows application. 
  9721. This process consists of a protected mode DDEServer, a Windows DDE ServerAgent, 
  9722. as described above, and a Presentation Manager DDE ServerAgent. The 
  9723. Presentation Manager DDE ServerAgent is a mirror to the Windows DDE 
  9724. ServerAgent. The ServerAgent is responsible for routing all DDE messages beyond 
  9725. the confines of Presentation Manager to the DDEServer. The ServerAgent 
  9726. communicates with the DDEServer via named pipes. 
  9727.  
  9728. The DDE process between Presentation Manager applications and Windows 
  9729. applications may be represented as in Figure "DDE Process between Presentation 
  9730. Manager and Windows". 
  9731.  
  9732. The following data formats are translated between the Presentation Manager 
  9733. environment and the Windows environment: 
  9734.  
  9735. Bitmaps:             Windows DIB format to/from OS/2 BITMAPINFO2 and 
  9736.                      Presentation Manager BITMAPINFO to/from Windows DIB 
  9737.                      format. 
  9738.  
  9739. Windows Device Dependent Bitmaps: Pre-Windows 3.0 format to Windows DIB format 
  9740.                      to/from Presentation Manager  BITMAPINFO. 
  9741.  
  9742. Windows Metafiles:   Metafiles are converted to Window DIB format prior to 
  9743.                      being translated as above. 
  9744.  
  9745. PM Metafiles:        PM metafiles are first converted to Window DIB format 
  9746.                      prior to being translated as above, and are then forwarded 
  9747.                      to the global clipboard. 
  9748.  
  9749. Text:                Codepage translation is provided in both directions, if 
  9750.                      required. 
  9751.  
  9752. Any data format which is not supported by the global DDEServer translation 
  9753. routines, can still be used on a local base, that means within the same VDM. 
  9754.  
  9755. The Presentation Manager DDE ServerAgent will reside as a utility in a 
  9756. Productivity folder on the Workplace Shell.  Where there is a demand to provide 
  9757. DDE support between Presentation Manager applications and Windows applications, 
  9758. the Presentation Manager DDE ServerAgent should be placed in the Workplace 
  9759. Startup folder.  The DDE ServerAgent runs only as a minimized icon. To shut 
  9760. down global DDE, the Presentation Manager  DDE ServerAgent must be terminated 
  9761. through the Window List. 
  9762.  
  9763. If a seamless Windows session is started, the DDE ServerAgent will 
  9764. automatically be started, so that this particular Windows application can 
  9765. automatically use DDE.  Otherwise, it would appear to be isolated and this 
  9766. would confuse the novice user. 
  9767.  
  9768. Existing DDE support between Presentation Manager applications remains 
  9769. essentially unchanged. Where DDE is only used between Presentation Manager 
  9770. applications, the DDEServer should be deactivated to improve performance. 
  9771.  
  9772.  
  9773. ΓòÉΓòÉΓòÉ 18.14. Object Linking and Embedding ΓòÉΓòÉΓòÉ
  9774.  
  9775. Object Linking and Embedding (OLE) focuses on document formats rather than on 
  9776. an application's ability to exchange data, as implemented using the DDE 
  9777. approach. OLE is concerned with sharing functionality as opposed to sharing 
  9778. data. The better the application of OLE, the less the concern with programs as 
  9779. opposed to their data. 
  9780.  
  9781. All OLE transactions involve a client application and a server application. The 
  9782. server creates the embedded or linked document and is activated when any 
  9783. activity beyond display is required; the client packages and renders the object 
  9784. within its own document. 
  9785.  
  9786. OLE objects are packaged within client documents either statically (embedded) 
  9787. or dynamically (linked).  The entire contents of an embedded object, including 
  9788. references to the server application, are included in the client document. 
  9789.  
  9790. OLE defines a format for compound documents which contain multiple forms of 
  9791. data. The data formats are understood and managed by multiple applications. The 
  9792. application uses various combinations of data to construct a compound document. 
  9793.  
  9794.  
  9795. ΓòÉΓòÉΓòÉ 18.14.1. OLE Concepts ΓòÉΓòÉΓòÉ
  9796.  
  9797. The concepts used in OLE are best described by contrasting them with the 
  9798. approach adopted by clipboard and DDE: 
  9799.  
  9800.  When using the clipboard, an application obtains data from another 
  9801.   application in a standard format, usually ASCII, a bitmap or a metafile. 
  9802.   This data exists only as data; there is no link with the application that 
  9803.   originally placed the data in the clipboard. 
  9804.  
  9805.  When using DDE, an application also obtains data from another application in 
  9806.   a standard format, such as ASCII, bitmap or metafile. However, the client can 
  9807.   establish and maintain a link with the application which delivered the data. 
  9808.   Should the data change in the server application, the client application's 
  9809.   data is also updated. 
  9810.  
  9811. OLE also enables an application to obtain data from another application; in 
  9812. this instance the data can be in two formats: 
  9813.  
  9814.  One format is understood only by the application sending the data 
  9815.  
  9816.  The display format (ASCII, bitmap or metafile) is understood by the receiving 
  9817.   application, and is used to display the data on the screen. 
  9818.  
  9819. When an object is linked, only the references to the actual data, including the 
  9820. name of the server application, are embedded within the client document. In 
  9821. both cases, the references allow the OLE libraries to execute the server and 
  9822. properly instruct it. 
  9823.  
  9824. When initially embedding or linking objects, client and server applications 
  9825. typically exchange data using the Windows clipboard. When the server puts data 
  9826. on the clipboard, it uses various combinations of four types of data: 
  9827.  
  9828.  1. Native data is specific to the server and likely to be alien to the client. 
  9829.  
  9830.  2. Presentation data uses one of several display formats commonly used by 
  9831.     Windows programs to render data. 
  9832.  
  9833.  3. OwnerLink data is the name and address identifying the object or 
  9834.     application that owns the data. 
  9835.  
  9836.  4. ObjectLink data uses the same format as OwnerLink data but describes the 
  9837.     application and object from which the data originated. 
  9838.  
  9839. The order in which this data is put on the clipboard, or otherwise presented to 
  9840. the client, determines what type of object is intended. 
  9841.  
  9842. For example, if OwnerLink data is presented first, then a linked object is 
  9843. intended. If Native data is first and OwnerLink is second, then the object can 
  9844. be embedded (though not necessarily rendered properly). 
  9845.  
  9846. In fact, a presentation format is optional for an embedded object, partly 
  9847. because some objects are meant to be invisible. If no presentation data is 
  9848. available and understood by the client and no object handler is provided by the 
  9849. server, the object will not be properly rendered by the client. 
  9850.  
  9851. The significance of this approach may be appreciated by way of an example. 
  9852. Voice annotation may be attached to a word processing application; the word 
  9853. processing application need not have any facility to support or manage voice. 
  9854. The word processor will store the data in two formats; the digitized sound and 
  9855. a display format (an icon). When the icon is selected in the document, a voice 
  9856. application is invoked and the word processing application passes the digitized 
  9857. sound to the voice application, which then plays the sound. 
  9858.  
  9859.  
  9860. ΓòÉΓòÉΓòÉ 18.14.2. Linking versus Embedding ΓòÉΓòÉΓòÉ
  9861.  
  9862. When an object is embedded, information from one document is inserted into a 
  9863. document in a different application. Embedding is similar to copying, but with 
  9864. one significant difference; to make changes to an embedded object, the user 
  9865. simply selects the object from within the destination document. The application 
  9866. in which the object was created is invoked, and the user may make the required 
  9867. changes.  There is no need to switch among applications to view or change 
  9868. different kinds of information; it is all in one document. 
  9869.  
  9870. When an embedded object is modified, the source document is not affected. For 
  9871. example, if a drawing is embedded into a report, changes made to the drawing 
  9872. within the report do not affect the original drawing which resides in its own 
  9873. file. 
  9874.  
  9875. When an object is linked, many documents can share a single item of 
  9876. information.  The object itself is not placed into the destination document; 
  9877. rather, a representation, or placeholder, for the object being linked is placed 
  9878. into the document.  The object still exists in the source document, and the 
  9879. destination document merely contains a link to the object's location in the 
  9880. source document. 
  9881.  
  9882. When changes are made to a linked object, the source document and any other 
  9883. documents linked to the object will reflect the changes. For example, if a 
  9884. drawing is linked to a report, any changes you make to the drawing appear in 
  9885. the source document and in any other reports linked with the drawing. 
  9886.  
  9887. Access may be gained to the object from any document that contains a link to 
  9888. it, and changes may be made to the object from within any such document. The 
  9889. updated version automatically appears in all the documents that have a link to 
  9890. this object. Linking makes it easy to track information that appears in more 
  9891. than one place and which must be identical. 
  9892.  
  9893. Only objects from saved documents may be linked.  For example, if a drawing is 
  9894. created using Paintbrush, the drawing must be saved as a document before it may 
  9895. be linked from another document. 
  9896.  
  9897. Not all applications can provide and accept objects. Some may only be the 
  9898. source of objects (server applications). Others (client applications) may only 
  9899. accept objects. 
  9900.  
  9901.  
  9902. ΓòÉΓòÉΓòÉ 18.15. Summary ΓòÉΓòÉΓòÉ
  9903.  
  9904. OS/2 Version 2.0 provides support for the execution of Windows applications 
  9905. within the MVDM architecture.  This support allows the concurrent execution of 
  9906. multiple Windows applications, using both real mode and standard mode, with 
  9907. DPMI and Windows services provided as required by a Windows kernel. 
  9908.  
  9909. Windows applications running under OS/2 Version 2.0 are provided with 
  9910. pre-emptive multitasking by the operating system.  Full memory protection is 
  9911. also provided for the Windows applications; an errant application may not 
  9912. affect other applications executing in the system.  A bug in an application 
  9913. will cause the termination of that application only. 
  9914.  
  9915. Windows applications may be run under OS/2 Version 2.0 in three ways: 
  9916.  
  9917.  Each application may run in its own VDM.  This method of execution provides 
  9918.   full protection for the application from other processes running in the 
  9919.   system, and protects these other processes from errors in the Windows 
  9920.   application. 
  9921.  
  9922.  Applications may share a VDM, and may be started and controlled within this 
  9923.   VDM using the Windows Program Manager.  This method of execution provides 
  9924.   protection for the Windows applications within the VDM from other processes, 
  9925.   and protection for other processes from errors in the Windows VDM's 
  9926.   applications.  However, the applications within the VDM may affect one 
  9927.   another since they share a common address space, just as if they were running 
  9928.   natively under DOS/Windows. 
  9929.  
  9930.  Windows applications may run "seamlessly" on the Workplace Shell  desktop, 
  9931.   along with windowed VDMs and Presentation Manager applications.  This method 
  9932.   of execution is similar to the case of a single application in a VDM, except 
  9933.   that the Windows application shares the Workplace Shell desktop rather than 
  9934.   running in its own full-screen session. 
  9935.  
  9936. Any combination of these three methods may be used concurrently. 
  9937.  
  9938. Windows applications may be defined on and started from the Workplace Shell 
  9939. desktop.  Where a single application is defined for a VDM, or where the 
  9940. application will run seamlessly, the icon used to represent the application on 
  9941. the desktop is the icon embedded within the Windows program which runs the 
  9942. application. 
  9943.  
  9944. During installation of OS/2 Version 2.0 over an existing DOS/Windows 3.0 
  9945. system, existing applications defined to the Windows Program Manager will be 
  9946. detected and migrated where possible to the OS/2 Version 2.0 Workplace Shell. 
  9947. The installation procedure uses application definition information contained in 
  9948. the Certified Application Database, which is shipped as part of the OS/2 
  9949. Version 2.0 product. 
  9950.  
  9951. OS/2 Version 2.0 allows communication between Windows applications running in 
  9952. the same or different VDMs, and between Windows applications and Presentation 
  9953. Manager applications.  This communication is provided through clipboard, DDE 
  9954. and OLE support.  Communication between Windows applications using shared 
  9955. memory is also supported, but only where Windows applications are executing in 
  9956. the same VDM. 
  9957.  
  9958. In summary, OS/2 Version 2.0 provides an integration platform which allows 
  9959. Windows applications to coexist with one another and with DOS and OS/2 
  9960. applications in a multitasking, fully protected environment, and which allows 
  9961. these applications to communicate with one another. 
  9962.  
  9963.  
  9964. ΓòÉΓòÉΓòÉ 19. DOS Protected Mode Interface ΓòÉΓòÉΓòÉ
  9965.  
  9966. Perhaps the most significant limitation of real mode operation, as used by DOS 
  9967. and similar operating systems, is the 1MB addressing limitation.  This 
  9968. limitation can be overcome by executing applications in protected mode, but 
  9969. since the DOS operating system and most TSR applications must run in real mode, 
  9970. problems arise when applications attempt to access interrupts, TSRs or 
  9971. operating system facilities. 
  9972.  
  9973. The DOS Protected Mode Interface (DPMI) is a protected mode programming 
  9974. interface for DOS applications, allowing such applications to run on an 80286 
  9975. or 80386 processor in protected mode, while utilizing the real mode services of 
  9976. the operating system and device drivers.  When an application wishes to access 
  9977. a DOS service, it makes a request to DPMI, which handles the appropriate 
  9978. address translations, switches the processor to real mode and makes the service 
  9979. request to DOS.  The result of the request is then translated to the correct 
  9980. format for the protected mode application, the processor is switched back to 
  9981. protected mode, and control is returned to the application. 
  9982.  
  9983. DPMI has been implemented in the Multiple Virtual DOS Machines component of 
  9984. OS/2 Version 2.0, and provides functions such as memory allocation and 
  9985. interrupt management for applications which use DPMI services. This support is 
  9986. provided through a component, implemented as a virtual device driver, known as 
  9987. the DPMI API Layer, in conjunction with the MVDM kernel. 
  9988.  
  9989. This chapter provides a brief overview of DPMI, and describes its 
  9990. implementation under OS/2 Version 2.0. 
  9991.  
  9992.  
  9993. ΓòÉΓòÉΓòÉ 19.1. DPMI Introduction ΓòÉΓòÉΓòÉ
  9994.  
  9995. Most processor instructions that are available in real mode may also be 
  9996. executed from a protected mode task.  Hence an application may overcome the 
  9997. limitations of real mode simply by executing in protected mode. However, direct 
  9998. access to physical hardware and interrupts is typically not permitted from a 
  9999. protected mode task running at Ring 3 privilege, and therefore DOS itself and 
  10000. many TSR programs must run in real mode. Protected mode specifications are such 
  10001. that communication between protected mode and real mode programs is difficult, 
  10002. making it difficult for an application to request services from DOS or a device 
  10003. driver. 
  10004.  
  10005. For example, a TSR, with which an application communicates through a software 
  10006. interrupt or a shared buffer, cannot run in protected mode.  The real mode 
  10007. address of the TSR, if used by the protected mode application, will not point 
  10008. to the same location in memory as would the same address if used in real mode, 
  10009. since the segment portion of the address is interpreted differently in the two 
  10010. modes.  Address conversion is therefore required when passing between the two 
  10011. modes. 
  10012.  
  10013. DPMI provides an interface between protected mode and real mode programs. DPMI 
  10014. consists of a set of protected mode functions which allow a DOS application to 
  10015. enter protected mode, allocate real mode memory, simulate real mode interrupts 
  10016. and function calls, intercept real mode interrupt vectors, etc.  By using these 
  10017. calls, an application running in protected mode can communicate with DOS or a 
  10018. TSR running in real mode. 
  10019.  
  10020. DPMI facilitates the following: 
  10021.  
  10022.  Allows DOS applications to run in protected mode 
  10023.  
  10024.  Provides DOS applications with access to a large memory address space 
  10025.  
  10026.  Provides DOS applications with mode switching and calls between real mode and 
  10027.   protected mode 
  10028.  
  10029.  Provides DOS applications running in protected mode with access to hardware 
  10030.   facilities such as debug registers, in a way that maintains system integrity. 
  10031.  
  10032. The term real mode is used to refer to code that runs in the low 1MB address 
  10033. space and uses segment:offset addressing.  Under many implementations of DPMI, 
  10034. so-called real mode software is actually executed in virtual 8086 mode.  Since 
  10035. virtual 8086 mode closely approximates real mode, V86 mode and real mode are 
  10036. interchangeable in the DPMI context. 
  10037.  
  10038. One of the major benefits offered by DPMI is that of allowing DOS extenders to 
  10039. work effectively in a multitasking, protected mode environment.  DOS extenders 
  10040. allow DOS applications to access extended memory while running in protected 
  10041. mode.  These extenders switch between modes as required to: 
  10042.  
  10043.  Execute application code in protected mode, in order to realize the enhanced 
  10044.   addressing capabilities and protection facilities of protected mode 
  10045.  
  10046.  Access DOS services and TSRs in real mode, to perform functions which cannot 
  10047.   be performed in protected mode. 
  10048.  
  10049. The Microsoft Windows/286 DOS extender (running under DOS on an 80286 
  10050. processor) was able to switch modes of its own accord. However, when running in 
  10051. virtual 8086 mode on an 80386 processor, a task cannot switch to protected 
  10052. mode; the required instruction is not legal for a V86 mode task. The 
  10053. architecture of DPMI, however, allows DOS extenders to request services using 
  10054. INT 31h DPMI calls; DPMI itself handles the mode switching and address 
  10055. conversion necessary to invoke the real mode services. 
  10056.  
  10057.  
  10058. ΓòÉΓòÉΓòÉ 19.2. Virtual Control Program Interface ΓòÉΓòÉΓòÉ
  10059.  
  10060. The forerunner to DPMI was the Virtual Control Program Interface (VCPI), 
  10061. developed by Phar Lap Software** and Quarterdeck Office Systems**.  VCPI 
  10062. allowed 80386-based protected mode DOS extenders to coexist with 80386-specific 
  10063. memory managers and expanded memory (EMS) emulators, such as QEMM-386 by 
  10064. Quarterdeck.  Most current 80386-specific software products support, or are 
  10065. capable of using, the VCPI interface. 
  10066.  
  10067. In VCPI, the DOS extender acts as a client and the EMS emulator acts as a 
  10068. server.  The client invokes the VCPI server to: 
  10069.  
  10070.  Switch between real mode and protected mode 
  10071.  
  10072.  Allocate memory 
  10073.  
  10074.  Program the interrupt controller(s) 
  10075.  
  10076.  Inspect or set the 80386 debug registers. 
  10077.  
  10078. If a DOS extender is loaded and a VCPI server is not present, the DOS extender 
  10079. may assume total control of the system and perform hardware-dependent 
  10080. manipulations directly. This can lead to system and data integrity problems. 
  10081.  
  10082. Note:   Do not confuse VCPI (Virtual Control Program Interface) with VPIC 
  10083.         (Virtual Programmable Interrupt Controller). 
  10084.  
  10085. While VCPI performs well for that which it was intended, it does not provide a 
  10086. platform for multitasking DOS extender applications.  The deficiency lies in 
  10087. VCPI allowing client programs to run in Ring 0, the highest privilege level 
  10088. possible under the 80386 processor. 
  10089.  
  10090. What was required was an interface capable of managing and controlling device 
  10091. initialization and providing centralized virtual memory management. Most 
  10092. important the interface had to shield one client from another. 
  10093.  
  10094.  
  10095. ΓòÉΓòÉΓòÉ 19.3. The DPMI Specification ΓòÉΓòÉΓòÉ
  10096.  
  10097. DPMI was devised by a committee of major software vendors.  The first (and 
  10098. current) DPMI version is Version 1.0. 
  10099.  
  10100. DPMI was defined to allow DOS programs to access extended memory while 
  10101. maintaining system protection.  DPMI defines a specific subset of DOS and BIOS 
  10102. calls that can be made by DOS programs running in protected mode. These 
  10103. services are accessed via software interrupt 31h, using a defined series of 
  10104. functions which protected mode programs may use to allocate memory, modify 
  10105. descriptors and call real mode software. 
  10106.  
  10107. Like VCPI, a DPMI host (or server) program provides mode switching and extended 
  10108. memory management services to client programs.  Unlike a VCPI server, however, 
  10109. a DPMI host runs at a higher privilege level than its clients.  A DPMI host 
  10110. supports demand-paged virtual memory and maintains complete control over the 
  10111. address space and hardware access of its clients. 
  10112.  
  10113. Some DPMI implementations execute multiple protected mode programs in 
  10114. independent virtual machines.  In such implementations, DPMI applications 
  10115. behave exactly like any other standard DOS programs.  For example, they can run 
  10116. in the background or in a window, provided the environment supports these 
  10117. features.  Programs that run in protected mode gain all the benefits of virtual 
  10118. memory and can utilize a 32-bit flat memory model if desired. OS/2 Version 2.0 
  10119. provides a DPMI implementation of this nature. 
  10120.  
  10121. DPMI services accessed via INT 31h are only available to protected mode 
  10122. programs.  Programs running in real mode cannot use these services.  The only 
  10123. exception to this rule is the service which allows an application to enter 
  10124. protected mode, which must be called by real mode programs before calling any 
  10125. other DPMI service. 
  10126.  
  10127. Note that the majority of software vendors who released applications using the 
  10128. VCPI specification have since released versions which use DPMI instead, or have 
  10129. produced upgrades to their software to take advantage of DPMI. 
  10130.  
  10131.  
  10132. ΓòÉΓòÉΓòÉ 19.3.1. DPMI Hosts and Clients ΓòÉΓòÉΓòÉ
  10133.  
  10134. DPMI services are provided by a DPMI host program.  Programs which use DPMI 
  10135. services are known as DPMI clients.  Generally, DPMI clients fall into two 
  10136. categories: 
  10137.  
  10138.  1. Extended applications 
  10139.  
  10140.  2. Applications that use DPMI directly. 
  10141.  
  10142. Most DPMI applications are likely to be extended applications.  These 
  10143. applications are bound with a DOS extender, which is the actual DPMI client 
  10144. since it requests DPMI services on the application's behalf.  The application 
  10145. calls DOS extender services, which are then translated by the DOS extender into 
  10146. DPMI service calls.  The advantage of an extended application over one that 
  10147. calls DPMI services directly is that generally, an extender will support 
  10148. functions other than DPMI services.  In fact, it is recommended that extenders 
  10149. look for extension services in the following order: 
  10150.  
  10151.  1. DPMI 
  10152.  
  10153.  2. VCPI/EMS 
  10154.  
  10155.  3. XMS 
  10156.  
  10157.  4. Top-down (INT 15h). 
  10158.  
  10159. Extended memory may be allocated "top-down" by hooking the BIOS extended memory 
  10160. size system call (INT 15h, function 88h) and reporting less memory available 
  10161. than is actually present on the machine.  This method may be used by DOS 
  10162. extenders to allocate a contiguous block of memory starting at the top of 
  10163. extended memory and growing downward.  Since other applications querying the 
  10164. amount of memory available in the system will not be able to "see" this upper 
  10165. portion of memory, the memory is available solely to the DOS extender. 
  10166.  
  10167. A DPMI client can provide a single set of functions to an application, and then 
  10168. translate these functions to one or more underlying services (for example, 
  10169. DPMI, EMS, and/or XMS) provided by the client.  Where the corresponding host's 
  10170. services are lacking in a particular function, the extender must itself provide 
  10171. that function for the application.  This is illustrated in Figure 
  10172. "Client/Server Structure for Operating System Extenders". 
  10173.  
  10174. As shown in Figure "Client/Server Structure for Operating System Extenders", 
  10175. application code directly accesses a set of base extender functions.  The 
  10176. extender then has separate modules for each type of extension service, and 
  10177. itself contains code to provide functions in which the underlying service 
  10178. layers are lacking. 
  10179.  
  10180. Readers should refer to the DPMI 1.0 Specification published by the DPMI 
  10181. committee for information concerning the external interfaces available to DPMI 
  10182. applications.  Copies of the specification may be obtained by contacting Intel 
  10183. Literature Sales, P.O. Box 58130, Santa Clara, CA 95052. 
  10184.  
  10185.  
  10186. ΓòÉΓòÉΓòÉ 19.3.2. DPMI Services ΓòÉΓòÉΓòÉ
  10187.  
  10188. The following is a brief outline of the DPMI services.  For details regarding 
  10189. invocation of DPMI services from an application via INT 31h, please refer to 
  10190. the DPMI 0.9 Specification. 
  10191.  
  10192. DPMI provides six main classes of services: 
  10193.  
  10194.  Local Descriptor Table management 
  10195.  
  10196.  Memory management 
  10197.  
  10198.  Page management 
  10199.  
  10200.  Interrupt management 
  10201.  
  10202.  Translation 
  10203.  
  10204.  Debug watchpoint. 
  10205.  
  10206. Each of these services is briefly described in the following sections. 
  10207.  
  10208. Note that DPMI services are normally never called by an application program 
  10209. itself, but are intended to be used by DOS extenders which request DPMI 
  10210. services on an application's behalf. 
  10211.  
  10212. LDT Descriptor Management Services 
  10213.  
  10214. The LDT descriptor management service provides interfaces for allocating, 
  10215. freeing, and creating protected mode descriptors in the current task's Local 
  10216. Descriptor Table (LDT).  Access to the Global Descriptor Table is not provided, 
  10217. so that the DPMI server can protect itself from protected mode applications and 
  10218. isolate these applications from one another. 
  10219.  
  10220. DOS Memory Management Services 
  10221.  
  10222. The DOS memory management services provided an interface from protected mode 
  10223. applications to real mode INT 21h functions which are used to allocate, free 
  10224. and resize memory blocks.  These services allow a protected mode applications 
  10225. to use memory below 640KB, to exchange data with DOS, ROM BIOS device drivers, 
  10226. TSRs and other real mode programs which are incapable of accessing data in 
  10227. extended memory. 
  10228.  
  10229. Extended Memory Management Services 
  10230.  
  10231. The extended memory management services are used to allocate, free and resize 
  10232. memory blocks above the 1MB boundary.  If the DPMI server is an 80386 or 80486 
  10233. control program and paging is enabled, the extended memory blocks are always 
  10234. allocated in units of 4KB. 
  10235.  
  10236. Page Management Services 
  10237.  
  10238. Under DPMI implementations which support virtual memory, applications may 
  10239. discard memory blocks or may not access them for long periods of time, in which 
  10240. case the memory block's contents may be swapped out to disk.  In certain 
  10241. circumstances, such as interrupt handling code, this swapping must be disabled 
  10242. and the appropriate pages locked in physical memory.  The page management 
  10243. services allow pages to be individually locked or unlocked. 
  10244.  
  10245. Interrupt Management Services 
  10246.  
  10247. These services allow protected mode applications to intercept real and 
  10248. protected mode interrupts and hook processor exceptions.  Certain services 
  10249. allow a protected mode program to intercept hardware or software interrupts 
  10250. which occur in real mode or protected mode, or to install handlers for 
  10251. processor exceptions.  Other interrupt services permit a process to enable or 
  10252. disable its own servicing or hardware interrupts without affecting the 
  10253. interrupt status of the entire system.  DPMI accomplishes this by maintaining a 
  10254. virtual interrupt flag on a per-process basis. 
  10255.  
  10256. Translation Services 
  10257.  
  10258. The translation services permit control to be passed between operating modes. 
  10259. A protected mode program may transfer control to a real mode routine using a 
  10260. simulated far call or a simulated interrupt.  Translation services also allow a 
  10261. protected mode program to declare a real mode callback, or entry point which 
  10262. can be invoked by the a real mode program. 
  10263.  
  10264. Debug Watchpoint Services 
  10265.  
  10266. The 80386 processor supports special registers that are used for debugging. 
  10267. Since the instructions to modify these registers can only be executed by code 
  10268. running at privilege level zero, protected mode debugging tools running in DPMI 
  10269. environments cannot modify the registers directly.  These services provide 
  10270. mechanisms for setting and clearing debug watchpoints and detecting when a 
  10271. watchpoint has caused a fault. 
  10272.  
  10273.  
  10274. ΓòÉΓòÉΓòÉ 19.4. DOS Extenders ΓòÉΓòÉΓòÉ
  10275.  
  10276. Programs which use DPMI services are normally bound to DOS extenders, in order 
  10277. to run under any DOS environment.  Most DOS extenders provide an interface to 
  10278. applications using an INT 21h multiplex.  For functions which utilize DPMI 
  10279. services, the DOS extender then makes the appropriate INT 31h request. 
  10280.  
  10281. Extenders that support DPMI will need to initialize differently when they are 
  10282. run under DPMI environments.  They will need to enter protected mode using the 
  10283. DPMI real to protected mode entry point, install their own API handlers, and 
  10284. then load the DOS extended application program. 
  10285.  
  10286. DOS extenders should check for the presence of DPMI before attempting to 
  10287. allocate memory or enter protected mode using any other API.  When DPMI 
  10288. services are detected, extenders that provide interfaces that extend or are 
  10289. different from the basic DPMI interface will switch into protected mode and 
  10290. initialize any internal data structures.  DPMI-compatible extenders that 
  10291. provide no API extensions should simply execute the protected mode application 
  10292. in real mode. 
  10293.  
  10294.  
  10295. ΓòÉΓòÉΓòÉ 19.4.1. Loading DPMI Clients and Extended Applications ΓòÉΓòÉΓòÉ
  10296.  
  10297. All DPMI applications begin execution in real mode.  An application must run 
  10298. first as a real mode DOS program, but can then switch to protected mode by 
  10299. making a call to DPMI (or to a DOS extender).  Once in protected mode, all INT 
  10300. 31h calls supported by DPMI may be issued by the application or its associated 
  10301. DOS extender functions. 
  10302.  
  10303. A DOS extender and its application under DPMI are loaded and initialized as 
  10304. described below.  The DOS extender: 
  10305.  
  10306.  1. Loads in real mode (or V86 mode on an 80386/80486 machine). 
  10307.  
  10308.  2. Checks for presence of a DPMI server. 
  10309.  
  10310.  3. Switches the CPU from real mode to protected mode, and loads registers with 
  10311.     the appropriate selectors. 
  10312.  
  10313.     If no DPMI server is present, the DOS extender checks for the existence of 
  10314.     a VCPI server or XMS device driver before assuming total control of the 
  10315.     CPU's execution mode, privileged control registers, and memory management 
  10316.     hardware. 
  10317.  
  10318.  4. Uses DPMI services to build the protected mode environment to be used by 
  10319.     the application. 
  10320.  
  10321.  5. Allocates extended memory segments to hold the application's code, data, 
  10322.     and stacks. 
  10323.  
  10324.  6. Allocates selectors to be used by the application to execute in and/or 
  10325.     address the memory segments. 
  10326.  
  10327.  7. Reads the application's code and data from disk into the segments. 
  10328.  
  10329.     The DOS extender can mark pageable memory it uses below 640KB so as to 
  10330.     reduce the demand for physical memory. 
  10331.  
  10332.  8. Installs its own handlers for any software interrupts (such as DOS INT 21h) 
  10333.     that the application will execute. 
  10334.  
  10335. Control is then passed to the application. 
  10336.  
  10337.  
  10338. ΓòÉΓòÉΓòÉ 19.4.2. Processing in DOS Extenders ΓòÉΓòÉΓòÉ
  10339.  
  10340. The way in which a DOS extender processes interrupts varies.  Some INT 21h 
  10341. requests are passed directly to DOS.  The DOS extender simply switches to real 
  10342. mode, calls DOS, and then switches back to protected mode when DOS returns 
  10343. after completing the function.  File input and output, however, may demand that 
  10344. the DOS extender translate addresses, while other INT 21h functions such as DOS 
  10345. memory management must be replaced entirely by the DOS extender. 
  10346.  
  10347. Unless the A20 address line has been explicitly enabled through the XMS 
  10348. interface, it cannot be assumed that memory from 1MB to 1MB+64KB-16 (the High 
  10349. Memory Area) is addressable once a program is running protected mode. If HMA is 
  10350. to be accessed, the A20 address line must be enabled through XMS before 
  10351. entering protected mode.  XMS calls are not supported in protected mode. 
  10352.  
  10353. This restriction is only important for software that wishes to access the HMA. 
  10354. Under all implementations of DPMI, the physical A20 address line will always be 
  10355. enabled while executing protected mode code.  However, some 80386 specific DPMI 
  10356. implementations simulate 1MB address wrap for compatibility reasons.  Under 
  10357. these DPMI implementations, the HMA will not be accessible unless the A20 
  10358. address line is enabled through the XMS interface.  This is the case under OS/2 
  10359. Version 2.0. 
  10360.  
  10361.  
  10362. ΓòÉΓòÉΓòÉ 19.4.3. Session Termination ΓòÉΓòÉΓòÉ
  10363.  
  10364. When the DOS extender or its application issue the DOS terminate interrupt, 
  10365. DPMI traps the interrupt and releases all of the application's protected mode 
  10366. resources.  The DPMI server passes the interrupt to real mode so as to permit 
  10367. DOS to clean up the program's real mode resources, including file and device 
  10368. handles and any memory blocks below 640KB. 
  10369.  
  10370.  
  10371. ΓòÉΓòÉΓòÉ 19.5. DPMI Implementation in OS/2 Version 2.0 ΓòÉΓòÉΓòÉ
  10372.  
  10373. OS/2 Version 2.0 provides DPMI services to applications running in VDMs.  The 
  10374. DPMI Version 0.9 specification is fully supported, and the architecture of the 
  10375. DPMI implementation is such that both the API functions and the underlying 
  10376. services are independently expandable to cope with future versions of DPMI. 
  10377.  
  10378. DPMI support under OS/2 Version 2.0 is divided into three components: 
  10379.  
  10380.  The DPMI API is implemented using the DPMI API Layer, a virtual device driver 
  10381.   which services INT 31h requests from applications. 
  10382.  
  10383.  The operating system kernel provides support for the DPMI VDD and the Virtual 
  10384.   Programmable Interrupt Controller (VPIC). 
  10385.  
  10386.  Protected mode hardware interrupts are routed via the VPIC. 
  10387.  
  10388. DPMI is service request driven.  An application first makes an INT 31H service 
  10389. request, which is handled by the DPMI VDD, calling the kernel for basic 
  10390. services such as allocating memory. 
  10391.  
  10392.  
  10393. ΓòÉΓòÉΓòÉ 19.5.1. DPMI Services ΓòÉΓòÉΓòÉ
  10394.  
  10395. DPMI services are requested using INT 31h requests, which are trapped by the 
  10396. DPMI virtual device driver, and either serviced by the VDD itself or routed to 
  10397. the operating system kernel. 
  10398.  
  10399. The DPMI API Layer performs input parameter checking on all service requests, 
  10400. to validate requests and to enforce restrictions mandated by the DPMI 
  10401. specification. 
  10402.  
  10403. LDT Descriptor Management 
  10404.  
  10405. The 8086 Emulation component of MVDM arranges for allocation of a task's LDT 
  10406. upon initialization of the VDM.  Under DPMI 0.9, all tasks in a VDM share the 
  10407. same LDT.  Applications may modify descriptors only through DPMI service calls. 
  10408.  
  10409. Three types of descriptors must be kept track of: 
  10410.  
  10411.  1. Per-task DPMI descriptors that the client may modify 
  10412.  2. V86 segment to selector mappings with descriptors that cannot be modified 
  10413.  3. Per-task DOS descriptors that the client cannot modify. 
  10414.  
  10415. Memory used by a DPMI application is allocated by the OS/2 Version 2.0 
  10416. operating system to the parent process of the VDM within which that application 
  10417. executes.  Full memory protection is therefore provided for applications using 
  10418. DPMI services. 
  10419.  
  10420. DOS Memory Management 
  10421.  
  10422. DOS memory management services are implemented under OS/2 Version 2.0 in 
  10423. various ways, according to the nature of the service. 
  10424.  
  10425.  Allocate DOS memory and selector set 
  10426.  
  10427.   This service allocates DOS memory along with a set of descriptors to cover 
  10428.   the allocation.  For 32-bit clients, a single descriptor is set to cover the 
  10429.   entire allocated region.  For 16-bit clients, this descriptor is followed by 
  10430.   descriptors to cover the rest of the region in 64KB segments.  This allows 
  10431.   16-bit applications to refer either through a single large segment or through 
  10432.   tiled selectors. 
  10433.  
  10434.   A V86 mode DOS call is used to allocate memory from the DOS arena. Therefore, 
  10435.   after initial setup, the DPMI API Layer switches back into V86 mode to issue 
  10436.   the DOS call, and then traps the return from DOS in order to finish the 
  10437.   service. 
  10438.  
  10439.  Free DOS memory and selector set 
  10440.  
  10441.   The allocated list is searched to make sure the region being freed is 
  10442.   allocated.  The allocation record is moved to the pending list with the 
  10443.   request marked as free.  A switch is then made to V86 mode and the INT 21h is 
  10444.   simulated as above with the return trapped.  When the return is trapped, 
  10445.   return values are set up.  If the call succeeded, the selectors that were 
  10446.   allocated are freed.  If a selector other than the allocated selector was 
  10447.   passed in the free call, that selector set is freed as well. 
  10448.  
  10449.  Resize DOS memory and selector set 
  10450.  
  10451.   Resizing is done in the same way as the original allocation.  The allocation 
  10452.   record is moved to the pending list.  The desired size is listed in the 
  10453.   allocation record and new selectors are allocated if the size increases and 
  10454.   new selectors are needed.  Descriptors are allocated before reflection so the 
  10455.   call can fail before allocating DOS memory in V86 mode if they are not 
  10456.   available.  The DOS call is then done as above. 
  10457.  
  10458.   If the call failed, the new selectors are freed when the hook regains 
  10459.   control.  If it succeeded, new descriptors are set up if they were needed or 
  10460.   descriptors are freed if the resize made some unnecessary. The return values 
  10461.   for the client are set up and the allocation record is returned to the 
  10462.   allocated list with its new size noted. 
  10463.  
  10464. Extended Memory Management 
  10465.  
  10466. Extended memory management services are also implemented in a number of ways, 
  10467. depending on the service. 
  10468.  
  10469.  Get memory information 
  10470.  
  10471.   This service uses memory management calls to load an application buffer with 
  10472.   a variety of information about the memory.  A VDH service is used to copy the 
  10473.   data to user space, with appropriate exception handling. 
  10474.  
  10475.  Allocate 
  10476.  
  10477.   Memory is allocated using a memory management service.  Record of the 
  10478.   allocation noting the start address, allocated size, and sparse linear 
  10479.   address size are kept in a hash table.  The allocation records are kept in 
  10480.   the DPMI API Layer per DPMI task area so that they can be cleaned up when the 
  10481.   task terminates. 
  10482.  
  10483.  Free 
  10484.  
  10485.   This function is implemented quite simply; the DPMI API Layer per-task data 
  10486.   area is checked for the allocation records, and the corresponding memory is 
  10487.   freed via a call to the operating system kernel. 
  10488.  
  10489.  Resize 
  10490.  
  10491.   DPMI changes a memory object's size in one of two ways: 
  10492.  
  10493.    - If the size of the object is to be decreased, pages at the end of the 
  10494.      object are decommitted. 
  10495.    - If the size of the object is to be increased, a new and larger object is 
  10496.      allocated and a kernel worker is used to move the pages from the original 
  10497.      object to the new one. 
  10498.  
  10499. Page Locking 
  10500.  
  10501. Page locking services are necessary on systems which deliver interrupts at 
  10502. interrupt time or which use DOS for paging.  On a system that simulates 
  10503. interrupts and has its own file system (such as OS/2 Version 2.0)  the calls 
  10504. are no-ops.  They will simply return a success indication to the client. 
  10505.  
  10506. Interrupt Hooking 
  10507.  
  10508. 8086 Emulation maintains a table of the current handler for each protect mode 
  10509. hook and exception.  These services are implemented by calling 8086 Emulation 
  10510. to get the current value from this table or to set a new value in the table. 
  10511.  
  10512. 8086 Emulation offers a service to change the client's virtual interrupt state 
  10513. (the IF flag). 
  10514.  
  10515. Translation (Protect/V86 Control Transfer) 
  10516.  
  10517. These services provide cross-mode calls, state saving, and raw mode switching. 
  10518.  
  10519.  Real mode callback (call protected mode from real mode) 
  10520.  
  10521.   This service allocates a real mode callback breakpoint.  When this breakpoint 
  10522.   is called, the DPMI API Layer handler arranges a protect mode call. 
  10523.  
  10524.  Free real mode callback 
  10525.  
  10526.   If a real mode callback is still waiting to be completed, the callback record 
  10527.   is marked to indicate it is no longer active.  Freeing the callback record 
  10528.   and the breakpoint are done when no outstanding calls are in progress. 
  10529.  
  10530.  State save/restore for each mode 
  10531.  
  10532.   This service returns a set of addresses, one for V86 mode and one for protect 
  10533.   mode, which, if called by the client, save or restore the current register 
  10534.   state for the other mode.  This is necessary for applications which perform 
  10535.   raw mode switching, to keep them from overwriting the task state for the 
  10536.   alternate mode. 
  10537.  
  10538.  Raw mode switching 
  10539.  
  10540.   This service returns a set of addresses, one for V86 mode and one for protect 
  10541.   mode, which, if called by the client, switch to the other mode. The 
  10542.   breakpoints have the DPMI task identifier in the breakpoint data area.  When 
  10543.   the breakpoint is reached, if the ID is different from the current one, 8086 
  10544.   Emulation is called to report the switch.  A VDH service is then used to do 
  10545.   the requested mode switch. 
  10546.  
  10547. Under OS/2 Version 2.0, an extension to the DPMI specification has been 
  10548. implemented, and is known as DOS API services.  Protected mode applications 
  10549. issuing DOS or BIOS calls must pass buffers that can be accessed in V86 mode. 
  10550. The DOS API services relieve the application from having to do this work for 
  10551. DOS calls and some BIOS calls.  This permits protected mode applications to use 
  10552. protect mode buffers (referenced by protected mode selectors) in DOS service 
  10553. requests.  The translation services perform any necessary buffer copying. 
  10554.  
  10555. Applications detect the presence of a DOS API translator by performing an INT 
  10556. 2Fh multiplex passing the name "MS-DOS" as an argument.  The translator 
  10557. responds when it detects this name, indicating that translation will be 
  10558. performed.  Applications that do not require translation may simply use the INT 
  10559. 31h simulate interrupt function to avoid translation. 
  10560.  
  10561. Debug Registers 
  10562.  
  10563. The Task Management component of OS/2 Version 2.0 manages watchpoints for OS/2 
  10564. applications, the kernel debugger and VDMs.  Interfaces for allocating, setting 
  10565. and freeing watchpoints and getting the Bx bits for allocated watchpoints are 
  10566. used by the DPMI API Layer to carry out these services.  The DPMI API Layer 
  10567. keeps track of allocated watchpoints in the per DPMI task area so that it can 
  10568. clean up at termination and uses the tasking watchpoint services to manipulate 
  10569. watchpoints. 
  10570.  
  10571. Other DPMI Services 
  10572.  
  10573. A number of other services are provided under the DPMI specification. Their 
  10574. implementation under OS/2 Version 2.0 is described below. 
  10575.  
  10576.  Physical Address Mapping 
  10577.  
  10578.   In OS/2 Version 2.0, there is no way of knowing which addresses are used by 
  10579.   device drivers.  It is therefore not safe to allow direct access to devices 
  10580.   which do not have VDDs.  However, direct access from within VDMs is allowed. 
  10581.  
  10582.   VDH services for reserving linear space, mapping, and page fault handling are 
  10583.   all restricted to regions below 1MB+64KB.  As such, a VDD with a linear 
  10584.   address above 1 MB cannot virtualize hardware.  All requests to this service 
  10585.   will fail.  The DPMI specification allows this so the operating system can 
  10586.   protect devices. 
  10587.  
  10588.  Get Vendor Specific Entry Point 
  10589.  
  10590.   Vendors that add extensions to DPMI typically look for the name of their 
  10591.   extension by hooking INT 31h.  If the extension is requested by a DPMI 
  10592.   client, the vendor-supplied routine issues an IRET instruction without 
  10593.   jumping down the INT 31h protect mode chain.  If the request is for a DPMI 
  10594.   service not supplied by the vendor's routine , the routine continues down the 
  10595.   INT 31h chain.  Since the DPMI API Layer router is called at the end of the 
  10596.   chain, any unrecognized service requests are signalled to the client by 
  10597.   setting the carry flag to indicate that the call failed. 
  10598.  
  10599.  
  10600. ΓòÉΓòÉΓòÉ 19.5.2. Kernel Support ΓòÉΓòÉΓòÉ
  10601.  
  10602. As well as providing support for DPMI service requests issued by applications, 
  10603. the operating system must also provide support for the internal control 
  10604. functions of the DPMI host.  This support is provided by various components of 
  10605. the operating system kernel. 
  10606.  
  10607. 8086 Emulation 
  10608.  
  10609. The 8086 Emulation component of MVDM emulates the 8086 hardware environment, 
  10610. and therefore provides a number of services which are used by DPMI. 
  10611.  
  10612.  DPMI task entry, termination, mode tracking, control 
  10613.  
  10614.   When the application calls the protect mode entry to switch to protected 
  10615.   mode, 8086 Emulation sets up tables for reflection of interrupts and 
  10616.   exceptions.  If the DPMI API Layer fails to complete the creation call, 8086 
  10617.   Emulation cleans up and returns the error to the application. 
  10618.  
  10619.  VDH service support 
  10620.  
  10621.   All support for VDH services to the DPMI API Layer is provided through 8086 
  10622.   Emulation. 
  10623.  
  10624.  Get/set support for protected mode handler interrupt and exception handlers. 
  10625.  
  10626.   Protected mode applications get and set vectors as in DOS.  8086 Emulation 
  10627.   maintains tables of protected mode interrupt handlers and exception handlers. 
  10628.  
  10629.  Interrupt and exception reflection to protected mode 
  10630.  
  10631.   8086 Emulation virtualizes interrupts for VDMs.  The reflection of "real 
  10632.   mode" interrupts to protected mode for DPMI applications is therefore 
  10633.   performed with the aid of 8086 Emulation. 
  10634.  
  10635.  Protected mode interrupt flag virtualization 
  10636.  
  10637.   8086 Emulation virtualizes the IF flag while in protected mode.  In V86 mode, 
  10638.   IOPL is usually 3 and applications directly change IF without trapping.  IF 
  10639.   flag virtualization is not done while in V86 mode because IOPL must be 3 to 
  10640.   cut down on overhead.  In protected mode, IOPL cannot be 3; otherwise no port 
  10641.   protection is possible.  Therefore, the IF flag is virtualized.  This 
  10642.   prevents VDMs from blocking real interrupts when running in protected mode. 
  10643.  
  10644.   To determine if interrupts are allowed in a VDM that has a DPMI application 
  10645.   running, the real IF bit in the CRF is checked.  If interrupts are disabled 
  10646.   here, then they are disabled.  Otherwise, the virtual IF flag indicates 
  10647.   whether interrupts are disabled. 
  10648.  
  10649.  HW interrupt support for the Virtual Programmable Interrupt Controller 
  10650.  
  10651.   8086 Emulation exports a VDH service to accept notification from the VPIC 
  10652.   when it starts and stops hardware interrupt reflection.  8086 Emulation also 
  10653.   tracks which hardware interrupts are hooked.  The VPIC allocates and 
  10654.   initializes the buffer at creation time in each VDM. 
  10655.  
  10656.   Any VDD can use this structure to determine if a particular IRQ is hooked. 
  10657.   The timer VDD, for example, can use this to avoid delivering timer ticks when 
  10658.   the timer tick interrupts are not hooked in either protected mode or in V86 
  10659.   mode. 
  10660.  
  10661.   When software interrupts are hooked, 8086 Emulation refers to this structure 
  10662.   to determine if the interrupt is a hardware interrupt. 
  10663.  
  10664.  Services to read/write user space with exception handling 
  10665.  
  10666.  Kernel and VDH service changes for exception handling when accessing user 
  10667.   address space. 
  10668.  
  10669.   Services called when the client is in protected mode, and which manipulate 
  10670.   the protected mode client address space, must be written to handle protected 
  10671.   mode user space access exceptions.  Services that cannot be called when the 
  10672.   client is in protected mode must specify this in their headers. 
  10673.  
  10674.   When a service can fault in protected mode, it must return a failure 
  10675.   indication to the DPMI client.  The client then cleans up and exits protected 
  10676.   mode so that the exception can be reflected to the VDM (in V86 mode). This 
  10677.   error also indicates whether a protected mode exception handler will be 
  10678.   called. 
  10679.  
  10680. Debug Watchpoint Management 
  10681.  
  10682. Coordinates watchpoint use with OS/2 protected mode and kernel debugger. 
  10683.  
  10684. Memory Management 
  10685.  
  10686. Among the kernel services provided by the Virtual Memory Manager are: 
  10687.  
  10688.  Allocate VDM LDT 
  10689.  
  10690.  Free VDM LDT 
  10691.  
  10692.  Allocate contiguous set of LDT descriptors 
  10693.  
  10694.  Free descriptor 
  10695.  
  10696.  Query maximum private linear address and ranges of physical memory 
  10697.  
  10698.  Query maximum linear region and swap space available 
  10699.  
  10700.  Other memory management services generally used by the kernel, such as 
  10701.   services to allocate, free, and set sparse allocations, are also used. 
  10702.  
  10703. Once descriptors are allocated they are changed directly by the DPMI API layer. 
  10704. Applications set descriptors only through requests to the DPMI API layer, which 
  10705. prevents settings that compromise protection. 
  10706.  
  10707.  
  10708. ΓòÉΓòÉΓòÉ 19.5.3. Ring 0 Exceptions ΓòÉΓòÉΓòÉ
  10709.  
  10710. All VDM linear addresses below 1MB + 64KB can be accessed by Ring 0 code (such 
  10711. as 8086 Emulation or DOS Emulation), without any exceptions being visible to 
  10712. the V86 mode application.  This meant that there was no need to recover from 
  10713. faults at ring 0 when VDM  applications ran only in V86 mode. 
  10714.  
  10715. DPMI protected mode applications, however, do have addresses in their address 
  10716. space that can cause visible exceptions at ring 0.  Most virtual device drivers 
  10717. are not affected because they never execute while the client is in protected 
  10718. mode.  VDDs are affected only if both of the following conditions are true: 
  10719.  
  10720.  The VDD runs while the client is in protected mode. 
  10721.  
  10722.  The VDD accesses the client address space above 1MB + 64KB or using client 
  10723.   selectors while the client is in protected mode.  This can happen indirectly 
  10724.   if a VDH service is called which manipulates the client's protected mode 
  10725.   stack. 
  10726.  
  10727. In such cases, the virtual device driver must include handlers for the 
  10728. exceptions. 
  10729.  
  10730.  
  10731. ΓòÉΓòÉΓòÉ 19.5.4. DPMI API Layer Communication with the Kernel ΓòÉΓòÉΓòÉ
  10732.  
  10733. The DPMI API Layer has a small, well defined interface with the kernel.  At 
  10734. system initialization time, the DPMI API Layer is registered with the kernel 
  10735. through a VDH call and reports which version of DPMI it supports.  If the VDD 
  10736. supports only DPMI Version 0.9, the kernel (which supports DPMI Version 1.0) 
  10737. adjusts the way in which it handles certain DPMI tasks. 
  10738.  
  10739. Kernel services that may be useful to VDDs other than the DPMI API layer are 
  10740. exported as VDH services.  Services that should have use restricted only to the 
  10741. DPMI API layer are made available through structures exchanged when the DPMI 
  10742. API Layer virtual device driver is registered. 
  10743.  
  10744.  
  10745. ΓòÉΓòÉΓòÉ 19.5.5. Installation of DPMI ΓòÉΓòÉΓòÉ
  10746.  
  10747. The OS/2 Version 2.0 installation procedure copies the DPMI API Layer virtual 
  10748. device driver DPM.SYS into the \OS2\MDOS directory on the user's system.  If 
  10749. users decide to use selective install, they can choose any combination of EMM, 
  10750. XMS, or DPMI.  When they select any of these memory options, the appropriate 
  10751. DEVICE= statement is added to CONFIG.SYS.  The default memory statement in 
  10752. CONFIG.SYS is: 
  10753.  
  10754. DEVICE=C:\OS2\MDOS\VEMM.SYS
  10755.  
  10756. If the user does not select DPMI support at installation time and wishes to add 
  10757. it at a later time, CONFIG.SYS must be modified by adding the statement: 
  10758.  
  10759. DEVICE=C:\OS2\MDOS\VDPMI.SYS
  10760.  
  10761.  
  10762. ΓòÉΓòÉΓòÉ 19.5.6. DPMI and Microsoft Windows ΓòÉΓòÉΓòÉ
  10763.  
  10764. DPMI 0.9 support is necessary for Windows 3.0 to run applications in protected 
  10765. mode (that is, in Windows standard mode).  With DPMI implemented in Windows 
  10766. 3.0, Windows 3.0 applications (running in protected mode) are freed from the 
  10767. restrictive 640KB DOS address space. 
  10768.  
  10769. Windows 3.0 is not a standard DPMI client and cannot run under DPMI in a VDM 
  10770. without completely subverting the operating system's memory protection and 
  10771. thereby potentially compromising system integrity. 
  10772.  
  10773. Even with DPMI, Windows cannot run in 386 enhanced mode under OS/2 Version 2.0. 
  10774. The reason for this is that when Windows runs in enhanced mode it operates at 
  10775. Ring 0.  Running Windows in 386 enhanced mode would therefore require bypassing 
  10776. the operating system's protection mechanisms, and would potentially compromise 
  10777. the integrity of the system. 
  10778.  
  10779.  
  10780. ΓòÉΓòÉΓòÉ 19.6. Summary ΓòÉΓòÉΓòÉ
  10781.  
  10782. Applications which experience memory constraints under DOS may overcome many of 
  10783. the inherent limitations of real mode by running protected mode. However, an 
  10784. application running in protected mode cannot easily access the facilities of 
  10785. real mode software such as the DOS operating system or TSR programs.  DPMI 
  10786. provides an interface which allows an application to execute in protected mode, 
  10787. and to make DOS requests through DPMI.  All mode switching and address 
  10788. conversion is handled by DPMI on the application's behalf. 
  10789.  
  10790. DPMI resolves problems relating to device virtualization, intertask protection, 
  10791. and demand paging that occur when multiple protected mode DOS extender 
  10792. applications are run in a multitasking environment, in conjunction with memory 
  10793. managers and control programs. 
  10794.  
  10795. DPMI is implemented under OS/2 Version 2.0 using a combination of virtual 
  10796. device driver services and kernel services to provide DPMI functions to client 
  10797. applications.  The provision of these functions allows applications written to 
  10798. use DPMI services, such as applications which run under Microsoft Windows in 
  10799. standard mode, to run in a VDM under OS/2 Version 2.0. 
  10800.  
  10801.  
  10802. ΓòÉΓòÉΓòÉ 20. Running DOS Applications ΓòÉΓòÉΓòÉ
  10803.  
  10804. OS/2 Version 2.0 allows the user to run multiple DOS applications concurrently, 
  10805. with each application running in its own virtual DOS machine, with pre-emptive 
  10806. multitasking and full memory protection. 
  10807.  
  10808. This chapter describes the way in which a DOS application can be defined to the 
  10809. OS/2 Version 2.0 Workplace Shell, and the ways in which an application may be 
  10810. started. It also discusses the way in which version-specific DOS applications 
  10811. may be run in virtual DOS machines under OS/2 Version 2.0. 
  10812.  
  10813.  
  10814. ΓòÉΓòÉΓòÉ 20.1. Defining a DOS Application ΓòÉΓòÉΓòÉ
  10815.  
  10816. A DOS application is typically defined to the Workplace Shell by creating a 
  10817. representative object for the application, and configuring the properties of 
  10818. that object using the settings view.  Configuring an object in this way allows 
  10819. the application to take advantage of the many customizable properties of the 
  10820. OS/2 Version 2.0 VDM  environment, and to tailor this environment to provide 
  10821. optimum performance and application compatibility. 
  10822.  
  10823.  
  10824. ΓòÉΓòÉΓòÉ 20.1.1. Creating a Representative Object ΓòÉΓòÉΓòÉ
  10825.  
  10826. To define a DOS application as an object under the Workplace Shell, do the 
  10827. following: 
  10828.  
  10829.  1. Open the Templates folder on the desktop, and copy the Program object by 
  10830.     pointing to it with the mouse pointer, holding down mouse button 2 and 
  10831.     dragging the icon to the desktop or to the folder in which the DOS 
  10832.     application will reside. 
  10833.  
  10834.  2. The settings view for the new object will automatically open. On the 
  10835.     Program page of the settings notebook, complete the Program title and Path 
  10836.     and file name fields for the application. The Parameters and Working 
  10837.     directory fields are optional, and depend on the application being 
  10838.     installed. Users should check the documentation supplied with the DOS 
  10839.     application. 
  10840.  
  10841.     Figure "The Program Page of the Settings Notebook" 
  10842.  
  10843.  3. On the Session page, select either DOS Window or DOS Full Screen, depending 
  10844.     on how the DOS application will be run.  In most cases, it is sufficient to 
  10845.     select DOS Window since when maximized, the window will allow the full 25 
  10846.     rows by 80 columns to be displayed. 
  10847.  
  10848.     Another advantage of selecting DOS Window is that the user can use the copy 
  10849.     and paste functions of the VDM to selectively transfer data between the DOS 
  10850.     application, the clipboard, and any other application on the desktop that 
  10851.     supports the clipboard. However, some graphics applications suffer 
  10852.     performance degradation when run in windowed mode. For such applications, 
  10853.     DOS Full Screen should be selected. 
  10854.  
  10855.     Note that once the VDM is started, a user can switch between DOS Window and 
  10856.     DOS Full Screen modes by holding down the Alt key and pressing the Home 
  10857.     key. 
  10858.  
  10859.     Do not confuse running a DOS application full screen with running it in a 
  10860.     full screen window (a maximized window that fills the entire screen). There 
  10861.     can be a significant performance difference between the two. 
  10862.  
  10863.     Note that clipboard function Copy All is also available for full screen 
  10864.     virtual DOS machines. This allows the user to copy the entire DOS full 
  10865.     screen to the clipboard (there is no way to mark only a portion of the 
  10866.     screen). To perform this function, the user must press Ctrl+Esc to return 
  10867.     to the desktop, click on the application icon with mouse button 2, and 
  10868.     select Copy All. 
  10869.  
  10870.  4. On the General page, complete the Title field. The user can optionally 
  10871.     choose to display a different icon from the default DOS Window or DOS Full 
  10872.     Screen icons. 
  10873.  
  10874.     Figure "The Session Page of the Settings Notebook" 
  10875.  
  10876.  5. If you select the DOS settings push button, the system brings up another 
  10877.     dialog. In this dialog, you can setup all DOS/VDM relevant characteristics, 
  10878.     unique to this particular program object. 
  10879.  
  10880.     Figure "The DOS Settings Dialog of the Settings Notebook" 
  10881.  
  10882. When the settings notebook is closed, the application will appear on the 
  10883. desktop or in the folder, with the specified application name beneath its icon. 
  10884.  
  10885.  
  10886. ΓòÉΓòÉΓòÉ 20.1.2. Adding TSRs to the Workplace Shell ΓòÉΓòÉΓòÉ
  10887.  
  10888. TSRs (Terminate-and-Stay-Resident) are DOS programs that stay resident in 
  10889. memory after terminating. This allows another DOS application to be loaded, 
  10890. while the TSR can still be accessed by a software or hardware interrupt, such 
  10891. as a hot-key sequence. An example is the dial-up terminal emulator FTTERM. 
  10892.  
  10893. A TSR will not work if it is added to the Workplace Shell using the steps in 
  10894. the previous section. The virtual DOS machine closes when it detects the TSR 
  10895. terminating and gives it no chance to become resident. 
  10896.  
  10897. Figure "Setting Up a TSR Program" 
  10898.  
  10899. To add a TSR to the Workplace Shell, do the following: 
  10900.  
  10901.  1. Open the Templates folder on the desktop, and copy the Program object to 
  10902.     the desktop or the required folder. 
  10903.  
  10904.  2. On the Program page of the settings notebook, complete the Program title 
  10905.     field with an asterisk ("*"). 
  10906.  
  10907.  3. Fill in the Parameters field with a "/k" followed by the path and program 
  10908.     name of the TSR. 
  10909.  
  10910.  4. Complete the Session and General pages of the settings notebook as for 
  10911.     other DOS applications. 
  10912.  
  10913.  
  10914. ΓòÉΓòÉΓòÉ 20.1.3. Customizing the VDM Environment ΓòÉΓòÉΓòÉ
  10915.  
  10916. The OS/2 Version 2.0 virtual DOS machine environment may be extensively 
  10917. customized to suit the requirements of a particular DOS application.  Such 
  10918. properties as DOS device drivers, EMS/XMS memory configurations, and even the 
  10919. interface to hardware facilities can be specified individually for each VDM. 
  10920.  
  10921. This customization is achieved using the DOS Settings facility, which is 
  10922. accessed by pressing the DOS settings pushbutton on the Session  page of the 
  10923. settings notebook. 
  10924.  
  10925. The DOS Settings facility and the available settings are described in detail in 
  10926. DOS Settings. 
  10927.  
  10928.  
  10929. ΓòÉΓòÉΓòÉ 20.1.4. Using the Migrating Applications Facility ΓòÉΓòÉΓòÉ
  10930.  
  10931. Many common DOS applications can be set up on the Workplace Shell with their 
  10932. virtual DOS machine customized automatically by using the Migrate Applications 
  10933. facility of the Systems Setup. There is a file in the \OS2\INSTALL subdirectory 
  10934. called DATABASE.DAT that contains information on commonly available DOS, 
  10935. Windows V3.0 and OS/2 Version 1.3 applications. For DOS and Windows V3.0 
  10936. applications this file includes the recommended DOS settings for the virtual 
  10937. DOS machine setup for that application. 
  10938.  
  10939. After installing the DOS application, start the Migrate Applicationsfacility 
  10940. and follow the dialog boxes to select the DOS application. If the migration is 
  10941. successful, an icon will be created for the application in a folder called DOS 
  10942. Applications. 
  10943.  
  10944. Refer to Installing and Migrating Applications on using the Migrate 
  10945. Applications program. 
  10946.  
  10947.  
  10948. ΓòÉΓòÉΓòÉ 20.2. Starting a DOS Application ΓòÉΓòÉΓòÉ
  10949.  
  10950. A DOS application can be started in a virtual DOS machine by a user in one of 
  10951. several ways: 
  10952.  
  10953.  By double-clicking mouse button 1 on the application's representative object 
  10954.   on the desktop or in a folder 
  10955.  
  10956.  By starting the application from an OS/2 or DOS command line 
  10957.  
  10958.  By running an OS/2 batch file containing the Start command with the 
  10959.   appropriate switches 
  10960.  
  10961. Note that an OS/2 application may also start a DOS application by issuing a 
  10962. DosExecPgm() function call. The DOS application can be started as a dependent 
  10963. or independent child process of the OS/2 application. 
  10964.  
  10965. There are certain limitations to starting DOS programs from an OS/2 V2.0 
  10966. command prompt. For example, neither output redirection (using the ">" 
  10967. character) nor piping (using the "|" character) works as it would from a DOS 
  10968. command prompt. When starting a DOS application from the OS/2 command prompt, 
  10969. OS/2 Version 2.0 calls the DOS command processor (COMMAND.COM), which then 
  10970. receives the application's name and parameters and starts it. The OS/2 V2.0 
  10971. command processor does not start the application itself but transfers all 
  10972. control to the DOS COMMAND.COM. When we use redirection or piping from the OS/2 
  10973. command prompt, it is only effective for the OS/2 session. Since OS/2 starts 
  10974. COMMAND.COM, and not the DOS application itself, OS/2 will only redirect the 
  10975. output of COMMAND.COM, not the application. 
  10976.  
  10977. Thus with a DOS program XYZ, neither: 
  10978.  
  10979. XYZ > DUMMY.FIL
  10980.  
  10981. nor: 
  10982.  
  10983. XYZ | more
  10984.  
  10985. would work from the OS/2 command prompt the way it does from a DOS command 
  10986. prompt. 
  10987.  
  10988. One solution to the above limitation is to put the redirection or piping 
  10989. statement into a DOS batch file and call the batch file instead. 
  10990.  
  10991.  
  10992. ΓòÉΓòÉΓòÉ 20.2.1. Starting From the Workplace Shell ΓòÉΓòÉΓòÉ
  10993.  
  10994. In order for an application to be started from within the Workplace Shell, it 
  10995. must first be defined and configured as described in Defining a DOS 
  10996. Application. Once this has been done, the application may be started simply by 
  10997. double-clicking mouse button 1 on the application's icon on the desktop or in a 
  10998. folder. 
  10999.  
  11000. Note that when the application is started, the background of the icon will 
  11001. change to indicate that the application is in use. By default, if the user 
  11002. double-clicks mouse button 1 on the icon a second time, the operating system 
  11003. will not start a second instance of the application, but will simply bring the 
  11004. already started instance to the foreground. 
  11005.  
  11006. If the user wishes to create a second instance of the application, a second 
  11007. representative object can be created by copying the original instance. 
  11008. Alternatively, the user can change the default behavior in the Window page of 
  11009. the settings notebook. 
  11010.  
  11011.  
  11012. ΓòÉΓòÉΓòÉ 20.2.2. Starting From the Command Line ΓòÉΓòÉΓòÉ
  11013.  
  11014. A DOS application can also be started from a DOS or OS/2 command line. Note, 
  11015. however, that starting the application in this way provides no opportunity to 
  11016. configure the VDM environment to support particular application requirements. 
  11017. Certain settings may be changed during application execution. However, such 
  11018. settings will be saved and will remain in effect until explicitly reset by the 
  11019. user. 
  11020.  
  11021. The default settings also allocate resources for EMS, XMS and DPMI support, 
  11022. which may not be required by the DOS application. For these reasons, it is 
  11023. recommended that DOS applications which require non-default settings be 
  11024. configured and started from the Workplace Shell wherever possible. 
  11025.  
  11026. When starting the application from a DOS command line, the application loads 
  11027. and executes within the VDM which displayed the command line. All DOS 
  11028. environment settings used by the application are those in effect for the VDM 
  11029. when the application was started. When the application terminates, control is 
  11030. returned to the command line. 
  11031.  
  11032. When starting the application from an OS/2 command line, the operating system 
  11033. reads the program file from disk, and determines from the executable file 
  11034. header that the program is a DOS or Windows application rather than an OS/2 
  11035. application. The operating system then automatically creates a VDM and loads 
  11036. the application into the VDM. When the application terminates, the VDM is also 
  11037. terminated and control returns to the OS/2 command line. 
  11038.  
  11039. Note that in either case, execution is synchronous, and the command line is not 
  11040. available for use while the application is running. An application may be 
  11041. started asynchronously from an OS/2 command line using the START command. In 
  11042. this case, the operating system creates an asynchronous VDM and loads the 
  11043. application into this VDM. The OS/2 command line remains available even though 
  11044. the DOS application is still running. 
  11045.  
  11046.  
  11047. ΓòÉΓòÉΓòÉ 20.3. Applications With Special Requirements ΓòÉΓòÉΓòÉ
  11048.  
  11049. The virtual DOS machine environment normally runs a specialized version of DOS 
  11050. known as the DOS Emulation kernel, in which most DOS services are actually 
  11051. provided by components of the OS/2 operating system, transparently to the 
  11052. application and outside of the real mode address space in which the DOS 
  11053. application executes. This kernel is described in MVDM DOS Emulation. 
  11054.  
  11055. For this reason, many DOS control structures are not accessible to DOS 
  11056. applications running in VDMs. Applications which access these control 
  11057. structures cannot be run in a "normal" VDM due to the lack of these structures. 
  11058. The DOS Emulation kernel does not support the use of block device drivers, and 
  11059. applications which require such device drivers are unable to use the DOS 
  11060. Emulation kernel. 
  11061.  
  11062. In order to allow such applications to be run in VDMs under OS/2 Version 2.0, 
  11063. the Virtual Machine Boot facility is provided. This facility allows a "real" 
  11064. version of DOS to be loaded into a VDM, either from a DOS bootable diskette or 
  11065. from a diskette image stored on fixed disk. Since the real version of DOS is 
  11066. therefore running in the VDM, all features, characteristics and internal 
  11067. control structures of that version are available to an application running in 
  11068. the VDM. 
  11069.  
  11070. An example of an application that needs to be run in this way is PC 
  11071. Support/400. 
  11072.  
  11073. The Virtual Machine Boot facility is described in detail in Virtual Machine 
  11074. Boot. 
  11075.  
  11076.  
  11077. ΓòÉΓòÉΓòÉ 20.4. Summary ΓòÉΓòÉΓòÉ
  11078.  
  11079. Multiple DOS applications may be run concurrently under OS/2 Version 2.0, in 
  11080. virtual DOS machines with pre-emptive multitasking and full memory protection. 
  11081. By default, these applications access DOS and hardware services using an 
  11082. emulated version of DOS, which provides these services through the OS/2 
  11083. operating system.  Most of these DOS services are provided outside the 640KB 
  11084. real mode address space in which the DOS application executes, thereby allowing 
  11085. more memory (up to 630KB) for the application and its data. 
  11086.  
  11087. DOS applications can usually be installed by starting a virtual DOS machine and 
  11088. running the install program from the command prompt. If the installation fails 
  11089. the user can boot the system from a DOS diskette to run the install, provided 
  11090. the hard disk has at least one FAT partition. 
  11091.  
  11092. A DOS application may be defined as an object on the OS/2 Version 2.0 Workplace 
  11093. Shell desktop or in a folder, and started from the Workplace Shell. 
  11094. Applications defined in this way have their VDM environment configured to 
  11095. support particular application requirements and to allow the application to 
  11096. take full advantage of VDM features. Alternatively, the Migrate Applications 
  11097. facility can be used to place the application in the Workplace Shell and 
  11098. customize the DOS settings 
  11099.  
  11100. A DOS application may also be started from the DOS or OS/2 command line. 
  11101. However, applications started from the DOS command line inherit the DOS 
  11102. environment settings of the VDM in which the command line is executing, and 
  11103. those started from the OS/2 command line inherit the default settings. 
  11104.  
  11105. DOS Applications which require access to internal DOS control structures or 
  11106. block device drivers not supported by the DOS Emulation kernel may use the 
  11107. Virtual Machine Boot facility of OS/2 Version 2.0 to load a "real" version of 
  11108. DOS from a diskette or a diskette image stored on fixed disk.  This capability 
  11109. allows such applications to run in a VDM. 
  11110.  
  11111.  
  11112. ΓòÉΓòÉΓòÉ 21. DOS Settings ΓòÉΓòÉΓòÉ
  11113.  
  11114. In order to provide the highest possible level of compatibility with DOS 
  11115. applications which make use of particular DOS properties or attributes, MVDM 
  11116. provides virtual DOS machines with many more customizable properties than 
  11117. comparable OS/2 sessions.  MVDM provides a common mechanism which supports 
  11118. standard settings, and allows virtual device drivers to register custom 
  11119. settings. The CONFIG.SYS file contains a number of standard DOS settings; 
  11120. these are applied to all VDMs as they are created.  Other settings may be 
  11121. specified for individual VDMs. 
  11122.  
  11123. When running Windows applications in VDMs under OS/2 Version 2.0, certain DOS 
  11124. settings should be altered from their default values.  The recommended values 
  11125. for these settings when running Windows applications are discussed in DOS and 
  11126. WIN-OS/2 Settings. 
  11127.  
  11128. DOS settings are used during creation and initialization of a VDM, and certain 
  11129. settings may also be altered dynamically during VDM execution. During 
  11130. initialization of the VDM, the VDM_CREATE hooks for all virtual device drivers 
  11131. defined for that VDM are called by the Virtual DOS Machine Manager.  At this 
  11132. point, the virtual device drivers may call the VDHQueryProperty() helper 
  11133. service to get the values for required settings. 
  11134.  
  11135.  
  11136. ΓòÉΓòÉΓòÉ 21.1. Registration ΓòÉΓòÉΓòÉ
  11137.  
  11138. Information on DOS settings is stored in a "database" in the operating system 
  11139. kernel.  This database is used to support all operations related to DOS 
  11140. settings.  The following information is registered for each setting: 
  11141.  
  11142. Name         The name presented to the user.  This may contain blanks, and 
  11143.              related settings should have common prefixes so that they sort 
  11144.              together in the list presented to the user (such as Printer buffer 
  11145.              size, Printer timeout, Printer automatic close). 
  11146.  
  11147. Ordinal      For the "standard" settings, specific ordinals are used so that 
  11148.              the kernel may obtain the value independently of the name string. 
  11149.  
  11150. Help File    The name of the help file containing help information on this 
  11151.              setting. 
  11152.  
  11153. Help ID      The help ID of the main topic for this setting. 
  11154.  
  11155. Type         The setting type.  The following types are supported: 
  11156.  
  11157.     Boolean 
  11158.     Integer 
  11159.     Enumeration (list  of  valid strings) 
  11160.     Single-line strings 
  11161.     Multi-line strings. 
  11162.  
  11163.              This allows the user interface to display an appropriate control 
  11164.              for each setting. 
  11165.  
  11166. Flags        These control aspects of the setting.  In particular, the flags 
  11167.              determine whether the setting can be changed while a VDM is 
  11168.              running. 
  11169.  
  11170. Default Value If the user does not supply a value, this default value is used. 
  11171.  
  11172. Validation information This information allows the user interface (and the 
  11173.              kernel) to validate settings without involvement from the virtual 
  11174.              device driver.  For strings, this is the maximum string length. 
  11175.              For integers, this is the minimum, maximum, and step values.  For 
  11176.              enumerations, this is the list of valid strings. 
  11177.  
  11178. Function     This function is used for validating string settings, and for 
  11179.              notifying the VDD when the user has changed a setting value for a 
  11180.              running VDM. 
  11181.  
  11182.  
  11183. ΓòÉΓòÉΓòÉ 21.1.1. Changing Settings Prior to Execution ΓòÉΓòÉΓòÉ
  11184.  
  11185. The Workplace Shell enables a user to define objects which represent OS/2 and 
  11186. DOS applications, using the Settings notebook.  For DOS applications, a DOS 
  11187. Settings... button is provided in the Session page of the notebook.  Pressing 
  11188. this button causes the DOS Settings dialog box to be displayed.  The user may 
  11189. then manipulate the DOS settings (which are initially set to their default 
  11190. values), and then save them. 
  11191.  
  11192. The DOS Settings dialog box uses the DosQueryDOSProperty() function to get the 
  11193. list of settings and detailed information on each setting.  It uses the 
  11194. DosSetDOSProperty() function to validate string settings. 
  11195.  
  11196.  
  11197. ΓòÉΓòÉΓòÉ 21.1.2. Changing Settings During Execution ΓòÉΓòÉΓòÉ
  11198.  
  11199. MVDM inserts a DOS Settings... menu item on the system menu for all VDMs. 
  11200. Selecting this menu item causes the DOS Settings dialog box to be displayed, 
  11201. which in turn allows the user to modify settings for the VDM.  For full screen 
  11202. VDMs, the user must switch to the Presentation Manager Window List using the 
  11203. Ctrl+Esc key sequence, and display the context menu for the VDM session by 
  11204. clicking mouse button 2 on the VDM's entry in the Window List.  The DOS 
  11205. Settings... option is displayed in the context menu. 
  11206.  
  11207. Note that only those settings that have been registered as being modifiable at 
  11208. run time may be altered in this way; other settings are not presented in the 
  11209. dialog box. 
  11210.  
  11211.  
  11212. ΓòÉΓòÉΓòÉ 21.1.3. Starting a VDM From Another Application ΓòÉΓòÉΓòÉ
  11213.  
  11214. The DosStartSession() function under OS/2 Version 2.0 provides an environment 
  11215. pointer as one of its parameters.  This pointer references a buffer which is 
  11216. used when creating a VDM.  This buffer contains the buffer length, followed by 
  11217. one or more DOS settings.  For each setting, the buffer specifies the type, 
  11218. name and value.  The operating system parses the settings buffer as part of the 
  11219. DosStartSession() processing, in order to create initial values for these 
  11220. settings.  Default values are assumed for any registered settings not specified 
  11221. in the DosStartSession() call. 
  11222.  
  11223. For any settings which have not been registered, the information in the buffer 
  11224. is ignored.  This allows the system to run without errors in the case where the 
  11225. virtual device driver that registered a setting is not loaded (for example, 
  11226. CONFIG.SYS was changed), and yet the Presentation Manager shell has saved a 
  11227. value for that setting. 
  11228.  
  11229.  
  11230. ΓòÉΓòÉΓòÉ 21.2. Standard DOS Settings ΓòÉΓòÉΓòÉ
  11231.  
  11232. Figure "The DOS Settings Dialog of the Settings Notebook" 
  11233.  
  11234. The standard DOS settings which affect the operation of virtual device drivers 
  11235. supplied with OS/2 Version 2.0 are described on the following pages.  The 
  11236. settings are grouped according to the general DOS system function to which they 
  11237. apply. 
  11238.  
  11239. DOS settings may be changed in either of two ways: 
  11240.  
  11241.  Settings which are described as settable "at VDM creation only", may only be 
  11242.   changed prior to starting the VDM.  If the DOS application is defined as an 
  11243.   object under the Workplace Shell, this is done by selecting the DOS Settings 
  11244.   button from the Session page in the application's Settings notebook. 
  11245.  
  11246.  Settings which are described as settable at any time may be set in the manner 
  11247.   described above, or they may be changed while an application is running in a 
  11248.   VDM, using the DOS Settings.. option from the system menu. 
  11249.  
  11250. Note that certain settings may be changed in both of the above ways. 
  11251.  
  11252.  
  11253. ΓòÉΓòÉΓòÉ 21.2.1. Communications ΓòÉΓòÉΓòÉ
  11254.  
  11255. The following settings control the communications environment (COM ports) used 
  11256. by a VDM. 
  11257.  
  11258. COM_HOLD 
  11259.  
  11260. Function:    When set on, provides exclusive access to COM ports for the 
  11261.              specified VDM, preventing other processes from using the port and 
  11262.              preventing the operating system from releasing the port until the 
  11263.              VDM terminates. 
  11264.  
  11265. Advantages:  For certain applications which use COM ports and which require 
  11266.              multiple programs to access the COM port (for example, this 
  11267.              setting prevents the COM port from being released when the first 
  11268.              program terminates). 
  11269.  
  11270. Drawbacks:   If not required by the application running in a VDM, this setting 
  11271.              may prevent other applications from accessing COM ports. 
  11272.  
  11273. Default:     Off. 
  11274.  
  11275. Settable:    At VDM creation only. 
  11276.  
  11277. Examples:    Certain bulletin board applications use one program to dial the 
  11278.              BBS and another to exchange information; setting COM_HOLD on 
  11279.              prevents the operating system from releasing the COM port when the 
  11280.              first program terminates. 
  11281.  
  11282.  
  11283. ΓòÉΓòÉΓòÉ 21.2.2. DOS Environment ΓòÉΓòÉΓòÉ
  11284.  
  11285. The following settings affect the behavior of the DOS emulation environment 
  11286. within a virtual DOS machine. 
  11287.  
  11288. DOS_BACKGROUND_EXECUTION 
  11289.  
  11290. Function:    When set off, suspends execution of the program when it is in the 
  11291.              background. 
  11292.  
  11293. Advantages:  Many DOS applications are written on the assumption that they are 
  11294.              single tasking and that all the resources of the workstation can 
  11295.              be monopolized. It is not uncommon  for a DOS program to 
  11296.              continually poll for keyboard input (Examples are WordPerfect 5.1 
  11297.              and Lotus 1-2-3 R2.2). In a multitasking environment, this can 
  11298.              impact system performance, especially when more than one such 
  11299.              program is running. Turning the DOS application off when its 
  11300.              virtual DOS machine is in the background reduces its demands on 
  11301.              the system. 
  11302.  
  11303.              Also see IDLE_SENSITIVITY and IDLE_SECONDS in Idle Detection. 
  11304.  
  11305. Drawbacks:   Communications programs will fail if background execution is 
  11306.              turned off, as will DDE for Windows applications. 
  11307.  
  11308.              Try changing the values of IDLE_SECONDS and IDLE_SENSITIVITY 
  11309.              before turning DOS_BACKGROUND_EXECUTION off. 
  11310.  
  11311. Default:     On (Background execution is enabled). 
  11312.  
  11313. Settable:    At any time. 
  11314.  
  11315. Examples:    If more than two DOS programs are running and tuning with 
  11316.              IDLE_SENSITIVITY and IDLE_SECONDS does not provide sufficient 
  11317.              improvement, turn DOS_BACKGROUND_EXECUTION off for the least used 
  11318.              application. 
  11319.  
  11320. DOS_BREAK 
  11321.  
  11322. Function:    Enables or disables Ctrl+Break for the specified VDM. Also check 
  11323.              for the BREAK statement in the CONFIG.SYS. Set BREAK=ON in the 
  11324.              CONFIG.SYS to make Ctrl+Break and Ctrl+C working in addition to 
  11325.              setting DOS_BREAK on. 
  11326.  
  11327. Advantages:  Enables a DOS application running in the VDM to be interrupted 
  11328.              using the Ctrl+Break or Ctrl+C key sequences. 
  11329.  
  11330. Drawbacks:   This setting is useful only if an application must be quickly 
  11331.              interrupted; the user may easily terminate a VDM by closing it 
  11332.              from the Window List. 
  11333.  
  11334. Default:     Off (Ctrl+Break is disabled). 
  11335.  
  11336. Settable:    At VDM creation only. 
  11337.  
  11338. Examples:    If the user wishes to have the option to interrupt a DOS batch 
  11339.              file running in a virtual DOS machine, this setting should be 
  11340.              turned on. 
  11341.  
  11342. DOS_DEVICE 
  11343.  
  11344. Function:    This setting can be used to add or modify information about DOS 
  11345.              device drivers for the specified VDM, in addition to the 
  11346.              information specified in CONFIG.SYS. 
  11347.  
  11348. Default:     When this setting is selected, a list is displayed which contains 
  11349.              information about each DOS device driver specified in CONFIG.SYS. 
  11350.              The information consists of the path and file name of each DOS 
  11351.              device driver and its current parameters, if applicable.  For 
  11352.              example: 
  11353.  
  11354.                           c:\os2\mdos\ansi.sys
  11355.  
  11356.              The user may: 
  11357.  
  11358.     Type the name of a DOS device driver to add it. Typing should begin on a 
  11359.      new line. 
  11360.     Delete all the information about a device driver to remove it. 
  11361.     Type or delete to add, change, or delete a value. 
  11362.  
  11363. Settable:    At VDM creation only. 
  11364.  
  11365. Examples:    A program to support hardware such as a scanner may include a 
  11366.              device driver that is needed only for itself. The device driver 
  11367.              should be loaded with the DOS_DEVICE setting instead of in the 
  11368.              CONFIG.SYS. 
  11369.  
  11370. DOS_FCBS 
  11371.  
  11372. Function:    Specifies the maximum number of file control blocks (FCBs) which 
  11373.              may be opened by applications running in the VDM. Note that this 
  11374.              setting affects only those modules which use file-sharing. 
  11375.  
  11376. Advantages:  Reducing this setting may improve DOS application performance in a 
  11377.              resource-constrained networking environment.  When the maximum 
  11378.              number of FCBs is opened by an application, the least recently 
  11379.              used FCB is closed to allow additional files to be opened; see 
  11380.              DOS_FCBS_KEEP below. 
  11381.  
  11382. Drawbacks:   Reducing this setting to an excessively low number may inhibit the 
  11383.              performance of applications which use large numbers of files. 
  11384.              Check application documentation for recommended FCB settings. 
  11385.  
  11386. Default:     16. 
  11387.  
  11388. Settable:    At VDM creation only. 
  11389.  
  11390. Examples:    None. 
  11391.  
  11392. DOS_FCBS_KEEP 
  11393.  
  11394. Function:    Specifies the number of FCBs that will be protected against 
  11395.              automatic closure. 
  11396.  
  11397. Advantages:  If this setting is specified as "n", the first "n" files are 
  11398.              protected against automatic closure as described in DOS_FCBS 
  11399.              above. This may improve application performance. 
  11400.  
  11401. Default:     8. 
  11402.  
  11403. Settable:    At VDM creation only. 
  11404.  
  11405. Examples:    None. 
  11406.  
  11407. DOS_FILES 
  11408.  
  11409. Function:    Specifies the maximum number of file handles which may be opened 
  11410.              in a VDM. 
  11411.  
  11412. Advantages:  Setting this value higher than the default may improve performance 
  11413.              for applications which use a large number of files.  Check 
  11414.              application documentation for recommended settings. 
  11415.  
  11416. Drawbacks:   Setting the number of file handles higher than necessary reduces 
  11417.              the available memory. 
  11418.  
  11419. Default:     20. 
  11420.  
  11421. Settable:    At any time. 
  11422.  
  11423. Examples:    DBASE IV requires a DOS_FILES setting of at least 40. 
  11424.  
  11425. DOS_HIGH 
  11426.  
  11427. Function:    Determines whether DOS is loaded outside the 640KB low memory 
  11428.              address space. 
  11429.  
  11430. Advantages:  Loading DOS into high memory allows more available memory for 
  11431.              application code and data within the 640KB address space. 
  11432.  
  11433. Drawbacks:   Applications which require access to DOS internal control 
  11434.              structures require DOS to be loaded into low memory, and therefore 
  11435.              cannot use this setting. 
  11436.  
  11437. Default:     Off (DOS is loaded into low memory). 
  11438.  
  11439. Settable:    At VDM creation only. 
  11440.  
  11441. Examples:    None. 
  11442.  
  11443. DOS_LASTDRIVE 
  11444.  
  11445. Function:    Specifies the highest available logical drive letter for the 
  11446.              specified VDM. This setting is similar to the LASTDRIVE= statement 
  11447.              in a DOS CONFIG.SYS. 
  11448.  
  11449. Default:     Z. 
  11450.  
  11451. Settable:    At VDM creation only. 
  11452.  
  11453. Examples:    Each additional drive letter uses about 100 bytes. Setting the 
  11454.              LAST_DRIVE to a lower letter such as J or K provides more 
  11455.              conventional memory for an application. 
  11456.  
  11457. DOS_RMSIZE 
  11458.  
  11459. Function:    Specifies the DOS memory size.  This is the amount of memory which 
  11460.              is available to DOS applications. 
  11461.  
  11462. Advantages:  The virtual video device driver uses this setting on certain video 
  11463.              adapters to set even more than 640KB. 
  11464.  
  11465. Drawbacks:   This setting is of little use to most users as there is no point 
  11466.              specifying less than 640KB. 
  11467.  
  11468. Default:     The default is 640KB. 
  11469.  
  11470. Settable:    At VDM creation only. 
  11471.  
  11472. Examples:    None. 
  11473.  
  11474. DOS_SHELL 
  11475.  
  11476. Function:    To specify the DOS command processor, or to add parameters to 
  11477.              affect the command processor.  This setting points by default to 
  11478.              COMMAND.COM.  If a user has a different command processor, it 
  11479.              should be specified here. 
  11480.  
  11481. Advantages:  The user may specify a command processor other than the default 
  11482.              COMMAND.COM, if required by a specialized application, or may 
  11483.              alter the environment space available for the VDM. 
  11484.  
  11485. Default:     C:\OS2\MDOS\COMMAND.COM C:\OS2\MDOS /P 
  11486.  
  11487. Settable:    At VDM creation only. 
  11488.  
  11489. Examples:    C:\OS2\MDOS\COMMAND.COM /E:1024 /P 
  11490.  
  11491. DOS_STARTUP_DRIVE 
  11492.  
  11493. Function:    Specifies the location of the DOS kernel to be loaded into the 
  11494.              VDM. 
  11495.  
  11496. Advantages:  Allows specific versions of DOS to be loaded into a VDM using the 
  11497.              VMB facility, allowing the execution of version-dependent DOS 
  11498.              applications. 
  11499.  
  11500. Drawbacks:   Performance may not be as good as the VDM kernel, which is 
  11501.              optimized for the OS/2 V2.0 environment. 
  11502.  
  11503. Default:     The DOS Emulation kernel is loaded. 
  11504.  
  11505. Settable:    At VDM creation only. 
  11506.  
  11507. Examples:    See Virtual Machine Boot. 
  11508.  
  11509. DOS_UMB 
  11510.  
  11511. Function:    Specifies whether DOS owns Upper Memory Blocks (UMBs) and manages 
  11512.              the loading of device drivers and TSR programs. 
  11513.  
  11514. Advantages:  Setting DOS_UMB on allows use of the DEVICEHIGH= and LOADHIGH 
  11515.              statements, to load device drivers and TSR programs into Upper 
  11516.              Memory Blocks, thereby preserving space in low memory for use by 
  11517.              applications. 
  11518.  
  11519. Drawbacks:   Certain applications which make use of UMBs need to access and 
  11520.              manage the UMBs directly; such applications will not run when 
  11521.              DOS_UMB is set on, because DOS owns the UMBs. 
  11522.  
  11523. Default:     Off (UMBs are owned by certain types of TSR programs and DOS 
  11524.              device drivers if necessary). 
  11525.  
  11526. Settable     At VDM creation only. 
  11527.  
  11528. Examples:    None. 
  11529.  
  11530. DOS_VERSION 
  11531.  
  11532. Function:    Allows the operating system to report a "fake" DOS version number 
  11533.              in response to a request from a program in the VDM, in order to 
  11534.              support applications which check for a DOS version number. 
  11535.  
  11536. Advantages:  Allows some programs that will not start unless they detect a 
  11537.              prerequisite DOS version to run in DOS Emulation 
  11538.  
  11539. Default:     20 
  11540.  
  11541. Settable:    Before application initiation. 
  11542.  
  11543. Examples:    Lotus 1-2-3 R3+ will run in DOS Emulation if it is "fooled" into 
  11544.              thinking that it is running under DOS 3.3 by putting the following 
  11545.              lines into the DOS_Version list box: 
  11546.  
  11547.     123DOS.EXE,3,30,255 
  11548.     123.EXE,3,30,255 
  11549.     LOTUS.EXE,3,30,255 
  11550.  
  11551.  
  11552. ΓòÉΓòÉΓòÉ 21.2.3. DPMI ΓòÉΓòÉΓòÉ
  11553.  
  11554. The following settings control the DPMI interface for a VDM. 
  11555.  
  11556. DPMI_DOS_API 
  11557.  
  11558. Function:    Determines whether DOS API translation is enabled for the 
  11559.              specified VDM. 
  11560.  
  11561. Default:     AUTO (API translation is enabled if required). 
  11562.  
  11563. Settable     At VDM creation only. 
  11564.  
  11565. Examples:    None. 
  11566.  
  11567. DPMI_MEMORY_LIMIT 
  11568.  
  11569. Function:    Specifies the maximum amount of protected mode memory (in 
  11570.              megabytes) available to DPMI applications running in the VDM. 
  11571.  
  11572. Advantages:  For applications which require large amounts of DPMI memory, this 
  11573.              setting may be used to increase the amount of available memory up 
  11574.              to 512MB. 
  11575.  
  11576. Default:     2MB. 
  11577.  
  11578. Settable     At VDM creation only. 
  11579.  
  11580. Examples:    None. 
  11581.  
  11582. DPMI_NETWORK_BUFF_SIZE 
  11583.  
  11584. Function:    Specifies the size, in kilobytes (KB), of the network translation 
  11585.              buffer for DPMI programs in this session. The range is from 1 to 
  11586.              64 KB. 
  11587.  
  11588. Default:     8KB. 
  11589.  
  11590. Settable     At VDM creation only. 
  11591.  
  11592. Examples:    This setting allows you to configure the size of the translation 
  11593.              buffer for Windows programs that transfer data over a network. If 
  11594.              a network-specific Windows program does not run correctly under 
  11595.              OS/2 V2.0, increase this setting, then restart  the session. 
  11596.  
  11597.  
  11598. ΓòÉΓòÉΓòÉ 21.2.4. EMS ΓòÉΓòÉΓòÉ
  11599.  
  11600. The following settings control the behavior of EMS memory used by the VDM. 
  11601.  
  11602. EMS_FRAME_LOCATION 
  11603.  
  11604. Function:    This DOS setting allows you to change the location of the LIM EMS 
  11605.              region. LIM EMS uses a 64KB address region known as an EMS page 
  11606.              frame, through which programs can access expanded memory. (This 
  11607.              allows programs to use more than 640KB of memory.) 
  11608.  
  11609. Advantages:  If a user has problems when running a program that uses both a 
  11610.              hardware device and LIM EMS expanded memory, the problem may be 
  11611.              due to conflicting use of addresses by LIM EMS and the hardware 
  11612.              device. If this occurs, the user should first use the 
  11613.              EMS_HIGH_OS_MAP_REGION setting to set the extra address region 
  11614.              used by EMS to 0. This may solve the problem. If the problem 
  11615.              persists, the EMS_FRAME_LOCATION setting can be used to select a 
  11616.              64KB region that does not conflict with hardware. 
  11617.  
  11618.              The user can choose where to place the frame from a list of 
  11619.              choices or can choose to have no EMS frame for programs which do 
  11620.              not require a frame.  The user can also reduce the DOS Memory Size 
  11621.              setting and place the frame below 640KB. 
  11622.  
  11623. Drawbacks:   The best solution, when problems due to hardware conflicts occur, 
  11624.              is to use the MEM_EXCLUDE_REGIONS and MEM_INCLUDE_REGIONS settings 
  11625.              to specify the addresses that the hardware uses rather than using 
  11626.              this setting. 
  11627.  
  11628. Default:     The default AUTO setting will lead to correct choices of LIM EMS 
  11629.              addresses.  Most users will never need to change this setting. 
  11630.  
  11631. Settable:    At VDM creation time only. 
  11632.  
  11633. Examples:    In some cases the default choice may conflict with addresses used 
  11634.              by hardware on the machine.  This can happen only for devices that 
  11635.              are not supported by a virtual device driver. 
  11636.  
  11637. EMS_HIGH_OS_MAP_REGION 
  11638.  
  11639. Function:    In addition to the EMS page frame, some programs can use 
  11640.              additional addresses to access expanded memory.  This setting 
  11641.              gives advanced users the capability to adjust the size of the 
  11642.              additional EMS region. 
  11643.  
  11644.              See also EMS_FRAME_LOCATION above. 
  11645.  
  11646. Advantages:  An advanced user can use the MEM_EXCLUDE_REGIONS and 
  11647.              MEM_INCLUDE_REGIONS settings to specify the addresses used by 
  11648.              devices that do not have virtual device drivers, and can then set 
  11649.              the size of the EMS_HIGH_OS_MAP_REGION appropriately for their 
  11650.              program. This helps avoiding conflicts with addresses used by 
  11651.              devices and programs. 
  11652.  
  11653. Default:     The value set is the size of the region in kilobytes.  The default 
  11654.              is 32KB. 
  11655.  
  11656. Settable:    At VDM creation only. 
  11657.  
  11658. Examples:    None. 
  11659.  
  11660. EMS_LOW_OS_MAP_REGION 
  11661.  
  11662. Function:    Some programs can use remappable conventional memory. Others do 
  11663.              not use this feature.  This setting allows advanced users to set 
  11664.              the size of the remappable conventional memory available in a VDM. 
  11665.  
  11666. Default:     The value set is the size of the region in kilobytes.  The default 
  11667.              is 384KB. 
  11668.  
  11669. Settable:    At VDM creation only. 
  11670.  
  11671. Examples:    None. 
  11672.  
  11673. EMS_MEMORY_LIMIT 
  11674.  
  11675. Function:    This setting controls the amount of EMS memory available to a VDM. 
  11676.  
  11677. Advantages:  The user can set this to a higher value for running programs that 
  11678.              require a large amount of EMS memory.  Other programs do not use 
  11679.              EMS at all.  The size can be set to 0 in such cases, to disable 
  11680.              EMS support for that VDM. Programs generally state whether they 
  11681.              use EMS on the box or in their manuals. 
  11682.  
  11683. Default:     The value set is the size of the region in kilobytes.  The default 
  11684.              size is 2MB. 
  11685.  
  11686. Settable:    At VDM creation time only. 
  11687.  
  11688. Examples:    If a spreadsheet runs out of memory, the amount of EMS memory can 
  11689.              be increased and the VDM restarted. 
  11690.  
  11691.  
  11692. ΓòÉΓòÉΓòÉ 21.2.5. Hardware Environment ΓòÉΓòÉΓòÉ
  11693.  
  11694. The following settings affect the virtual hardware environment provided by the 
  11695. virtual DOS machine. 
  11696.  
  11697. HW_NOSOUND 
  11698.  
  11699. Function:    Enables or disables sound started by a DOS program. 
  11700.  
  11701. Advantage:   Any sound from a program is heard unless sound is disabled.  An 
  11702.              "x" in the check box indicates that the sound is to be heard. 
  11703.  
  11704. Drawbacks:   No error sound will be heard if HW_NOSOUND is turned on. 
  11705.  
  11706. Default:     OFF. 
  11707.  
  11708. Settable:    At any time, including while a program is running in a VDM. 
  11709.  
  11710. Examples:    Output from a music program may be disabled when the user wishes 
  11711.              to hear another music program, or switch to another process to do 
  11712.              something else. 
  11713.  
  11714. HW_ROM_TO_RAM 
  11715.  
  11716. Function:    Enabling HW_ROM_TO_RAM causes the operating system to copy 
  11717.              read-only memory (ROM) and run the copy in 32-bit random access 
  11718.              memory (RAM).  With this setting enabled, BIOS operations run 
  11719.              faster and system utilities may patch BIOS. 
  11720.  
  11721. Default:     OFF. 
  11722.  
  11723. Settable:    At VDM creation only. 
  11724.  
  11725. Examples:    This setting is useful if debugging the kernel.  The change would 
  11726.              allow normal breakpoints to be set in ROM and allow stepping over 
  11727.              calls and loops. 
  11728.  
  11729.              Warning:  If an application writes to a memory address used by the 
  11730.              ROM while this setting is enabled, it may cause unpredictable 
  11731.              results for that application and for every application run 
  11732.              thereafter in the VDM. 
  11733.  
  11734.  
  11735. HW_TIMER 
  11736.  
  11737. Function:    When enabled, allows an application to have direct access to the 
  11738.              8253 timer ports and prevents the operating system from trapping, 
  11739.              or intercepting, the timer request and emulating a timer. 
  11740.  
  11741. Advantages:  Certain timing-critical applications will not run (or will run 
  11742.              much slower) if accesses to timer ports are trapped and 
  11743.              virtualized.  In addition, the values they read do not accurately 
  11744.              reflect the amount of time passed because they do not take 
  11745.              trapping overhead into account.  Enabling this setting allows 
  11746.              certain timing-dependent code to run more effectively. 
  11747.  
  11748. Drawbacks:   Applications that change the divisor before this setting is 
  11749.              enabled and then read the timer ports after the setting has been 
  11750.              enabled may not function properly.  If the setting is enabled 
  11751.              first, the VDM will not detect changes to the divisor correctly, 
  11752.              and the simulated interrupt frequency will be incorrect.  Also, 
  11753.              multiple applications using this setting may interfere with one 
  11754.              another. 
  11755.  
  11756. Default:     Off.  Most applications will operate normally with timer 
  11757.              virtualization. 
  11758.  
  11759. Settable:    At any time.  It is useful to alter this setting dynamically and 
  11760.              watch for changes in application performance. 
  11761.  
  11762. Examples:    The ROMs on some machines implement very brief delays by polling 
  11763.              the timer ports.  These delays become unacceptably long unless 
  11764.              direct timer port access is allowed. 
  11765.  
  11766.  
  11767. ΓòÉΓòÉΓòÉ 21.2.6. Idle Detection ΓòÉΓòÉΓòÉ
  11768.  
  11769. The following settings determine the way in which the operating system detects 
  11770. that an application in a VDM is currently idle.  These settings should be used 
  11771. when an application exhibits poor performance, or where mouse movement in a DOS 
  11772. application is "jerky". 
  11773.  
  11774. IDLE_SECONDS 
  11775.  
  11776. Function:    When programs appear to be doing nothing but waiting for input, 
  11777.              the operating system gives them less time to run. This is done to 
  11778.              give preference to programs that are doing useful work.  Some 
  11779.              programs periodically appear to be waiting for input, but then 
  11780.              change their behavior and continue after a time.  This setting 
  11781.              disables the "IDLE_SENSITIVITY" function for a period of time 
  11782.              after useful work has been detected. 
  11783.  
  11784.              Also see IDLE_SENSITIVITY below for more details on idle 
  11785.              detection. 
  11786.  
  11787. Advantages:  If a program appears to run slowly when there is an option for the 
  11788.              user to provide input, this value should be increased. 
  11789.  
  11790. Drawbacks:   Setting the value too high gives the DOS program more resources 
  11791.              than it needs. 
  11792.  
  11793. Default:     This value is in seconds.  The default is no idle time allowed. 
  11794.  
  11795. Settable:    The setting can be changed while the program is running to tune it 
  11796.              to the proper value. 
  11797.  
  11798. Examples: 
  11799.  
  11800.     A game may pause, for instance, to wait for the user to make a choice, but 
  11801.      then continues if the user does not react. 
  11802.  
  11803.     When DOS 5 is run in a virtual machine boot session, (See Virtual Machine 
  11804.      Boot) the DOS shell may fail to complete displaying the directory of the 
  11805.      C: drive if IDLE_SENSITIVITY is set too low. IDLE_SECONDS should then be 
  11806.      raised. 
  11807.  
  11808. IDLE_SENSITIVITY 
  11809.  
  11810. Function:    The idle sensitivity level sets a threshold for judging when 
  11811.              applications will be considered idle.  The value is the percentage 
  11812.              of the maximum possible polling rate the application can perform. 
  11813.              If an application polls at a rate higher than this value, it is 
  11814.              considered "idle". 
  11815.  
  11816.              DOS programs often "poll" for input when they are waiting for a 
  11817.              user response.  For instance, a program may wait for a response by 
  11818.              repeatedly checking to see if the user has hit a key.  In a 
  11819.              multitasking environment such as OS/2 Version 2.0, this wastes 
  11820.              time when other programs could be running instead.  The operating 
  11821.              system detects idle programs by looking for a high rate of polling 
  11822.              for input.  When programs are judged to be waiting for input, they 
  11823.              are given less time to run. 
  11824.  
  11825.              For example, if idle sensitivity is set to 75%, then an 
  11826.              application repeatedly checking to see if input is available would 
  11827.              have to do this checking at more than 75% of the maximum possible 
  11828.              rate before it would be judged idle. 
  11829.  
  11830.              Idle detection is a "best guess" of what the program is doing.  It 
  11831.              could be that the program is polling at a very high rate, but is 
  11832.              still doing useful work in between checking.  It may be that the 
  11833.              application checks at a fairly slow rate but still is doing 
  11834.              nothing but waiting. The idle sensitivity threshold allows 
  11835.              adjustment of the threshold for a particular application. 
  11836.  
  11837.              Also see IDLE_SECONDS above. 
  11838.  
  11839. Advantages:  If an application receives input while running and seems to run 
  11840.              slower than expected, the idle sensitivity should be set to a 
  11841.              higher value.  This lets the application poll at a higher rate 
  11842.              without being judged idle.  Setting the level to 100 turns idle 
  11843.              detection off altogether.  The application will be allowed to poll 
  11844.              for input as often as it likes. 
  11845.  
  11846.              If an application is waiting for input and other applications do 
  11847.              not appear to be running, the idle sensitivity should be adjusted 
  11848.              downward.  This lowers the threshold for judging the application 
  11849.              idle. 
  11850.  
  11851. Default:     The default is 75%. 
  11852.  
  11853. Settable:    The setting can be changed while the program is running to tune it 
  11854.              to the proper value. 
  11855.  
  11856. Examples:    Overall system performance can usually be improved when there are 
  11857.              multiple DOS applications running if IDLE_SENSITIVITY is turned 
  11858.              down. 
  11859.  
  11860.              Also see Dos Environment (DOS_BACKGROUND_EXECUTION). 
  11861.  
  11862.  
  11863. ΓòÉΓòÉΓòÉ 21.2.7. Keyboard ΓòÉΓòÉΓòÉ
  11864.  
  11865. The following settings affect the behavior of the keyboard and the 
  11866. interpretation of control key sequences issued within a VDM. 
  11867.  
  11868. KBD_ALTHOME_BYPASS 
  11869.  
  11870. Function:    When enabled, prevents the Alt+Home key sequence from switching 
  11871.              the VDM between full screen and windowed mode. 
  11872.  
  11873. Advantages:  Enabling this setting allows normal behavior for applications 
  11874.              which themselves make use of the Alt+Home key sequence. 
  11875.  
  11876. Drawbacks:   When enabled, the user must use the Ctrl+Esc sequence to switch to 
  11877.              Presentation Manager from a full screen VDM, then use the context 
  11878.              menu of the class to switch the VDM to windowed mode. 
  11879.  
  11880. Default:     Off (Alt+Home will cause a switch between full screen and windowed 
  11881.              mode). 
  11882.  
  11883. Settable:    At any time. 
  11884.  
  11885. Examples:    None. 
  11886.  
  11887. KBD_BUFFER_EXTEND 
  11888.  
  11889. Function:    Increases a VDM's keyboard type-ahead buffer size. 
  11890.  
  11891. Advantages:  Provides greater keystroke buffering, consistent with the level 
  11892.              available in VIO windows.  Note that Ctrl-Break will flush the 
  11893.              entire buffer, just as it does with the standard buffer. 
  11894.  
  11895. Drawbacks:   Applications which bypass the ROM BIOS input buffer and/or INT 16h 
  11896.              may not benefit from this feature.  There is also a small amount 
  11897.              of additional memory overhead for every VDM. 
  11898.  
  11899. Default:     On.  Most applications will benefit, and those that do not should 
  11900.              not be adversely affected. 
  11901.  
  11902. Settable:    At any time.  This facilitates easy experimentation by the user in 
  11903.              the (rare) event that a problem does arise. 
  11904.  
  11905. Examples:    None. 
  11906.  
  11907. KBD_CTRL_BYPASS 
  11908.  
  11909. Function:    When enabled, inhibits one or more control key sequences, allowing 
  11910.              an application in the VDM to use these sequences for its own 
  11911.              purposes. 
  11912.  
  11913. Advantages:  Enabling this setting allows normal behavior for applications 
  11914.              which make use of control key sequences normally used by OS/2 
  11915.              Version 2.0. 
  11916.  
  11917. Drawbacks:   Enabling this setting may prevent certain operations from being 
  11918.              performed with OS/2 Version 2.0 and the Workplace Shell. 
  11919.  
  11920. Default:     NONE (All control key sequences behave in the normal manner). 
  11921.  
  11922. Settable:    At any time. 
  11923.  
  11924. Examples:    None. 
  11925.  
  11926. KBD_RATE_LOCK 
  11927.  
  11928. Function:    Prevents a DOS application in a VDM from changing the system 
  11929.              keyboard repeat rate. 
  11930.  
  11931. Advantages:  Insulates machine from applications that modify the repeat rate in 
  11932.              an uncontrolled or undesirable way. 
  11933.  
  11934. Drawbacks:   Prevents the application's repeat rate from taking effect even 
  11935.              when the application is the focus session. 
  11936.  
  11937. Default:     Off.  Most applications do not modify the repeat rate, and those 
  11938.              that do are generally in accordance with the user's wishes. 
  11939.  
  11940. Settable:    At any time. 
  11941.  
  11942. Examples:    None. 
  11943.  
  11944.  
  11945. ΓòÉΓòÉΓòÉ 21.2.8. Memory Extenders (EMS and XMS) ΓòÉΓòÉΓòÉ
  11946.  
  11947. The following settings affect the behavior of the EMS and XMS memory extenders, 
  11948. if used in the VDM.  For an explanation about the implementation of EMS and XMS 
  11949. support in VDMs, see Memory Extender Support. 
  11950.  
  11951. MEM_EXCLUDE_REGIONS 
  11952.  
  11953. Function:    This setting is used to specify address ranges which should be 
  11954.              protected from use by EMS/XMS and direct access by applications. 
  11955.              This setting is intended for experienced users who understand the 
  11956.              hardware. 
  11957.  
  11958. Advantages:  This setting restricts the use of EMS/XMS on certain ranges in the 
  11959.              region between RMSIZE and 1MB.  It also protects these ranges from 
  11960.              being touched by user applications by portraying ROM there. 
  11961.  
  11962. Drawbacks:   Some hardware adapters stop functioning if their addresses are 
  11963.              touched in random fashion.  If these ranges are defined 
  11964.              excessively, they will adversely impact the function and 
  11965.              performance of EMS and XMS services. 
  11966.  
  11967. Default:     By default, this setting is void.  Each address is specified in 
  11968.              hex and if there is no range specified, the length taken is a page 
  11969.              (4KB). 
  11970.  
  11971. Settable:    At VDM creation only. 
  11972.  
  11973. Examples:    None. 
  11974.  
  11975. MEM_INCLUDE_REGIONS 
  11976.  
  11977. Function:    Specify regions which should be made available to EMS/XMS. This 
  11978.              setting is used to specify some address ranges between RMSIZE and 
  11979.              1MB for use by EMS and XMS. 
  11980.  
  11981. Advantages:  If there is a hardware adapter in this range which the user knows 
  11982.              is not going to be used by a particular VDM session, then the 
  11983.              address range used by this adapter should be made available to EMS 
  11984.              and XMS.  This will improve the performance of EMS and XMS 
  11985.              services.  Only advanced users who know the addresses used by a 
  11986.              card should use this setting. 
  11987.  
  11988. Default:     By default, this setting is void. 
  11989.  
  11990. Settable:    At VDM creation only. 
  11991.  
  11992. Examples:    See discussion in Expanded Memory (EMS) and Upper Memory (UMB). 
  11993.  
  11994.  
  11995. ΓòÉΓòÉΓòÉ 21.2.9. Mouse ΓòÉΓòÉΓòÉ
  11996.  
  11997. The following settings affect the behavior of the mouse in a VDM. 
  11998.  
  11999. MOUSE_EXCLUSIVE_ACCESS 
  12000.  
  12001. Function:    This setting allows VDMs to run applications which maintain their 
  12002.              own mouse pointers.  Some DOS applications manage their own mouse 
  12003.              positions and movements; in many cases, the application's values 
  12004.              for mouse sensitivity and/or double speed threshold are different 
  12005.              from those of Presentation Manager.  As a result, a Presentation 
  12006.              Manager mouse pointer may be outside the VDM window while the 
  12007.              application pointer is somewhere in the window not receiving any 
  12008.              mouse events. This means having two asynchronous mouse pointers on 
  12009.              the screen. 
  12010.  
  12011. Advantages:  The user forces the physical mouse driver to send its events 
  12012.              directly to the virtual mouse driver without going through 
  12013.              Presentation Manager.  Only one mouse pointer appears when the 
  12014.              particular VDM window has the focus. 
  12015.  
  12016. Default:     OFF. 
  12017.  
  12018. Settable:    At any time. 
  12019.  
  12020.              However, this only marks the VDM window and does not actually 
  12021.              activate the setting.  In order to activate it, the user must 
  12022.              press a mouse button within the VDM window.  The Presentation 
  12023.              Manager pointer disappears, leaving only the application pointer. 
  12024.              In order to regain the Presentation Manager pointer, the user must 
  12025.              press any of the hot-keys (Alt, Ctrl+Esc, Shift+Esc). 
  12026.  
  12027. Examples:    WordPerfect 5.1 has its own block-shaped mouse pointer, which will 
  12028.              appear together with the system mouse pointer when the window has 
  12029.              the focus. Turning MOUSE_EXCLUSIVE_ACCESS on allows the user to 
  12030.              remove the system mouse pointer when in WordPerfect. 
  12031.  
  12032.  
  12033. ΓòÉΓòÉΓòÉ 21.2.10. Printer ΓòÉΓòÉΓòÉ
  12034.  
  12035. The following settings affect print functions within a VDM. 
  12036.  
  12037. PRINT_TIMEOUT 
  12038.  
  12039. Function:    Use this setting to adjust the amount of time, in seconds, that 
  12040.              the OS/2 V2.0 print subsystem waits before forcing a print job to 
  12041.              the printer. In DOS, information sent by a program for printing 
  12042.              goes directly to a printer. However, the OS/2 V2.0 print subsystem 
  12043.              assembles print information in a spool file. After a specified 
  12044.              period of time, during which the spool file does not grow larger, 
  12045.              OS/2 V2.0 print subsystem sends the information to the printer as 
  12046.              a single print job. 
  12047.  
  12048. Advantage:   There is no need to exit the DOS program before the print job is 
  12049.              released by the OS/2 V2.0 print subsystem.  This is useful for 
  12050.              applications which do not explicitly close their print jobs. 
  12051.  
  12052. Default:     15 seconds, configurable from 0 to 3600 seconds (0 seconds is no 
  12053.              timeout). 
  12054.  
  12055. Settable:    At any time. 
  12056.  
  12057. Examples:    A timeout of 1 or 2 seconds is sufficient for small print jobs, 
  12058.              such as copying the contents of the screen. However, when printing 
  12059.              large files, formatting documents, or running calculations, the 
  12060.              value must be set high enough to allow all print results to reach 
  12061.              the spooler before the time limit expires.  If not, results go in 
  12062.              two or more spool files instead of one, and the resulting output 
  12063.              may be unsatisfactory. 
  12064.  
  12065.  
  12066. ΓòÉΓòÉΓòÉ 21.2.11. Video ΓòÉΓòÉΓòÉ
  12067.  
  12068. The following settings control screen I/O operations within a VDM. 
  12069.  
  12070. VIDEO_FASTPASTE 
  12071.  
  12072. Function:    Speeds up input from other sources than the keyboard. 
  12073.  
  12074. Advantages:  Improves the speed of paste operations from the clipboard to a DOS 
  12075.              application. 
  12076.  
  12077. Drawbacks:   Does not work with all applications (in particular, some 
  12078.              applications which monitor keyboard interrupts directly may 
  12079.              experience errors). 
  12080.  
  12081. Default:     Off. 
  12082.  
  12083. Settable:    At any time.  This facilitates easy experimentation by the user. 
  12084.  
  12085. Examples:    Pasting into the DOS command prompt, or any application using DOS 
  12086.              Console I/O functions, will generally work. However, the Microsoft 
  12087.              Editor (M) and its successor, Programmer's Workbench (PWB), can 
  12088.              fail when using fast pasting because they rebuffer keystrokes in 
  12089.              an internal buffer, which can overflow. 
  12090.  
  12091. VIDEO_MODE_RESTRICTION 
  12092.  
  12093. Function:    Extends the 640KB DOS address space by limiting video mode 
  12094.              support. 
  12095.  
  12096. Advantages:  For text-based or CGA graphics based applications, the video 
  12097.              memory normally reserved just above 640KB for high-resolution 
  12098.              graphics modes can be remapped to conventional memory, providing 
  12099.              an additional 64KB (or 96KB, depending on graphics mode) for DOS 
  12100.              applications, TSRs, and other programs.  This is valuable for 
  12101.              applications that do not take advantage of EMS or XMS memory 
  12102.              extenders. 
  12103.  
  12104. Drawbacks:   It is not possible to completely hide the fact that the video 
  12105.              adapter is high-resolution graphics-capable;  some applications 
  12106.              may attempt to enable those modes and use the memory above 640KB 
  12107.              as video memory, inadvertently corrupting application data.  Care 
  12108.              must therefore be taken when using this feature. 
  12109.  
  12110. Default:     NONE.  The complete list of settings is: 
  12111.  
  12112.     None 
  12113.  
  12114.     CGA modes only (adds 96KB) 
  12115.  
  12116.     MONO modes only (adds 64KB). 
  12117.  
  12118. Settable:    At VDM creation only. 
  12119.  
  12120. Examples:    None. 
  12121.  
  12122. VIDEO_ONDEMAND_MEMORY 
  12123.  
  12124. Function:    Reduces swap space requirements for fullscreen VDMs. 
  12125.  
  12126. Advantages:  Allows a full-screen VDM to run without pre-allocating a virtual 
  12127.              video buffer for the worst-case video modes (high-resolution 
  12128.              graphics modes).  Using this setting does not prevent execution of 
  12129.              graphics applications; it simply means that allocation of the 
  12130.              buffer is delayed until it is needed.  This can save a substantial 
  12131.              amount of memory/swap space, which might be important under 
  12132.              certain low-memory conditions. It also enables you to start a 
  12133.              program quickly. 
  12134.  
  12135. Drawbacks:   If allocation of a virtual video buffer for a full-screen VDM 
  12136.              fails at the time the application changes video modes, the session 
  12137.              must be frozen and switched back to the shell.  Unless the user is 
  12138.              able to free memory from another session, he may be unable to get 
  12139.              the DOS application running again.  This is a concern if the 
  12140.              application contains unsaved data. 
  12141.  
  12142. Default:     Off. 
  12143.  
  12144. Settable:    At any time.  This allows the user to save memory the next time 
  12145.              the session is switched to full-screen. 
  12146.  
  12147. Examples:    None. 
  12148.  
  12149. VIDEO_RETRACE_EMULATION 
  12150.  
  12151. Function:    Simulates the video retrace status port to provide faster access. 
  12152.  
  12153. Advantages:  DOS applications that poll the video retrace status port often 
  12154.              write to the screen only during the retrace interval, even though 
  12155.              it is safe (on EGA and VGA adapters) to draw at any time without 
  12156.              causing interference (also known as "snow").  This feature causes 
  12157.              most applications to write to the screen more often, and 
  12158.              compensates for the performance drag imposed by monitoring the 
  12159.              port in the first place. 
  12160.  
  12161. Drawbacks:   Some applications may poll the port in such a way that overall 
  12162.              performance is worse; this is sometimes true of applications that 
  12163.              draw only during vertical (not horizontal) retrace. 
  12164.              Unfortunately, while turning off trace emulation will restore 
  12165.              performance, there is a risk that screen-switching will not be as 
  12166.              reliable. 
  12167.  
  12168. Default:     On.  Reliable screen-switching has higher priority over the 
  12169.              minority of applications that will experience some drag in 
  12170.              performance. 
  12171.  
  12172. Settable:    At any time.  This allows the user to experiment with different 
  12173.              settings in the event of a performance problem. 
  12174.  
  12175. Examples:    None. 
  12176.  
  12177. VIDEO_ROM_EMULATION 
  12178.  
  12179. Function:    Emulates selected INT 10h ROM Video functions. 
  12180.  
  12181. Advantages:  Provides faster output for selected video functions than ROM 
  12182.              services typically provide.  This also has a dramatic effect on 
  12183.              the performance of those functions in a window. 
  12184.  
  12185. Drawbacks:   Some ROMs may offer enhanced services that are not included in the 
  12186.              emulation.  Applications which rely upon these services may not 
  12187.              execute correctly. 
  12188.  
  12189. Default:     On.  Because the INT 10h ROM Video services are well-documented, 
  12190.              incompatibilities are unlikely and the performance benefits of 
  12191.              using the emulation are quite significant. 
  12192.  
  12193. Settable:    At any time.  This allows the user to experiment in the event of a 
  12194.              compatibility problem. 
  12195.  
  12196. Examples:    None. 
  12197.  
  12198. VIDEO_SWITCH_NOTIFICATION 
  12199.  
  12200. Function:    Notifies a DOS application of a switch to/from full-screen mode. 
  12201.  
  12202. Advantages:  Allows applications that monitor this notification to redraw their 
  12203.              screens as needed.  This may be necessary for some video adapters 
  12204.              that provide modes (and applications that use those modes) which 
  12205.              are not fully supported by the OS/2 video driver or which are 
  12206.              slightly incompatible.  It is also valuable in situations where an 
  12207.              OS/2 video driver has not allocated a virtual video buffer (see 
  12208.              VIDEO_8514_XGA_IOTRAP below). Use this setting if you use the 
  12209.              VIDEO_ONDEMAND_MEMORY DOS setting, because concurrent buffer 
  12210.              allocation and screen switching can make a screen go black. 
  12211.  
  12212. Drawbacks:   When used indiscriminately, this feature may cause unnecessary and 
  12213.              time-consuming screen redrawing.  For standard MONO/CGA/EGA/VGA 
  12214.              video modes, the OS/2 video driver should be able to restore 
  12215.              application screens without assistance. 
  12216.  
  12217. Default:     Off.  For standard hardware and standard video modes, this feature 
  12218.              is not necessary. 
  12219.  
  12220. Settable:    At any time.  This allows the user to experiment in the event of a 
  12221.              compatibility problem. 
  12222.  
  12223. Examples:    Windows 2.x and 3.x understand this notification and will redraw 
  12224.              themselves accordingly. For WIN-OS/2 sessions, set this setting 
  12225.              on. 
  12226.  
  12227. VIDEO_WINDOW_REFRESH 
  12228.  
  12229. Function:    Adjusts the window update frequency for a given VDM. 
  12230.  
  12231. Advantages:  For applications (particularly graphics) that write frequently to 
  12232.              video memory, this value can be increased to reduce time spent 
  12233.              updating the window and provide more processor time for the 
  12234.              application. 
  12235.  
  12236.              Note:   This has no effect on updates based on other events such 
  12237.                      as keyboard input or synchronous scrolling operations or 
  12238.                      any video events other than refresh.
  12239.  
  12240. Drawbacks:   A large refresh period can make an application unusable (or at 
  12241.              least, very hard to use). 
  12242.  
  12243. Default:     0.1 seconds.  This has been found to yield the best overall 
  12244.              performance. 
  12245.  
  12246. Settable:    At any time, in increments of 0.1 seconds.  This allows for 
  12247.              experimentation.  The range is from 0.1 to 60.0 seconds. 
  12248.  
  12249. Examples:    This setting affects normal TTY-style output.  Compare a DIR or 
  12250.              TYPE operation before and after altering this setting. 
  12251.  
  12252. VIDEO_8514_XGA_IOTRAP 
  12253.  
  12254. Function:    When set OFF, unrestricted access to 8514/A display adapter 
  12255.              hardware.  Note that this setting is only available for systems 
  12256.              with 8514/A display adapters installed. 
  12257.  
  12258. Advantages:  Achieves higher performance for 8514/A applications and eliminates 
  12259.              the overhead of the 1MB 8514/A virtual video buffer normally 
  12260.              allocated for each VDM when set OFF. 
  12261.  
  12262. Drawbacks:   Screen-switching away from the application will result in 
  12263.              immediate freezing of the application, and the system may not be 
  12264.              able to reliably switch back; that is, the screen image may not be 
  12265.              correct.  This may be overcome by setting 
  12266.              VIDEO_SWITCH_NOTIFICATION on, which notifies applications to 
  12267.              redraw their own screen images.  Note however, that not all 
  12268.              applications will take advantage of the notification. 
  12269.  
  12270.              Note:   An application with this setting enabled may not be run in 
  12271.                      windowed mode, or copied to the clipboard, because there 
  12272.                      is no complete information about its state.
  12273.  
  12274. Default:     Off. 
  12275.  
  12276. Settable:    At VDM creation only. 
  12277.  
  12278. Examples:    When executing Windows 3.0 with the 8514/A display driver, certain 
  12279.              operations such as painting dithered backgrounds will run 
  12280.              significantly faster. 
  12281.  
  12282.  
  12283. ΓòÉΓòÉΓòÉ 21.2.12. XMS ΓòÉΓòÉΓòÉ
  12284.  
  12285. XMS_HANDLES 
  12286.  
  12287. Function:    Specifies the number of XMS extended memory block (EMB) handles. 
  12288.              A handle is used with each XMS EMB.  This number is required 
  12289.              because XMS pre-allocates all the handle space to be compatible 
  12290.              with XMS specifications.  This setting should be used only if an 
  12291.              application uses a large number of handles. 
  12292.  
  12293. Advantages:  This setting restricts the number of block handles, thereby 
  12294.              reducing memory consumption. 
  12295.  
  12296. Drawbacks:   Specifying a large number of handles will increase memory 
  12297.              consumption and adversely impact system performance. 
  12298.  
  12299. Default:     The default value of this setting is 32. 
  12300.  
  12301. Settable:    At VDM creation only. 
  12302.  
  12303. Examples:    None. 
  12304.  
  12305. XMS_MEMORY_LIMIT 
  12306.  
  12307. Function:    Specifies the per VDM XMS memory limit. This setting should be 
  12308.              used under the same guidelines as described above in XMS_HANDLES. 
  12309.              The global limit is the overall maximum XMS memory consumption, 
  12310.              and the per-VDM limit is the maximum allowed for each VDM. See 
  12311.              also Extended Memory Manager (Initialization) for defining global 
  12312.              and per-VDM limit in the CONFIG.SYS. 
  12313.  
  12314. Drawbacks:   Specifying a large number may adversely affect system performance. 
  12315.  
  12316. Default:     The default value is 2MB per-VDM. 
  12317.  
  12318. Settable:    At VDM creation only. 
  12319.  
  12320. Examples:    4096; this specifies a limit for each VDM. 
  12321.  
  12322. XMS_MINIMUM_HMA 
  12323.  
  12324. Function:    Specifies the minimum HMA memory request allowed.  This setting 
  12325.              allows the user to fine tune the XMS.  HMA is slightly less than 
  12326.              64KB in size.  Only one request can be fulfilled from this area at 
  12327.              a time. 
  12328.  
  12329. Advantages:  If a TSR takes a very small allocation, then it will waste this 
  12330.              area for other applications.  In such cases a limit can be 
  12331.              specified. 
  12332.  
  12333. Default:     The default value is zero, which means all the requests will be 
  12334.              allowed. 
  12335.  
  12336. Settable:    At VDM creation only. 
  12337.  
  12338. Examples:    2048; this sets a limit of 2KB. 
  12339.  
  12340.  
  12341. ΓòÉΓòÉΓòÉ 21.2.13. WIN-OS/2 ΓòÉΓòÉΓòÉ
  12342.  
  12343. The following setting is available when the selected virtual DOS machine type 
  12344. is WIN-OS/2 full screen or WIN-OS/2 window: 
  12345.  
  12346. WIN_RUNMODE 
  12347.  
  12348. Function:    OS/2 V2.0 can use two modes to run Windows programs: 
  12349.  
  12350.     Real 
  12351.     Standard 
  12352.  
  12353.              Real mode is the mode that Windows 2.0 programs run in. Windows 
  12354.              3.0 programs usually run in standard mode. For a detailed 
  12355.              discussion, see Windows Applications. Use this setting to specify 
  12356.              WIN-OS/2 mode for your session. 
  12357.  
  12358. Default:     AUTO (the system selects standard mode as long as it has the OS/2 
  12359.              V2.0 Virtual Device Drivers required to support a standard mode 
  12360.              WIN-OS/2 session in the OS/2 V2.0 operating system). AUTO enables 
  12361.              the system to automatically choose between real and standard. 
  12362.  
  12363. Settable:    At VDM creation only. 
  12364.  
  12365. Examples:    None. 
  12366.  
  12367.  
  12368. ΓòÉΓòÉΓòÉ 21.3. Summary ΓòÉΓòÉΓòÉ
  12369.  
  12370. The DOS Settings feature of MVDM provides the user with the ability to 
  12371. selectively configure and tune the virtual DOS machine environment to meet the 
  12372. requirements of particular applications.  Since some DOS applications require 
  12373. certain features while other applications operate better without them, a VDM 
  12374. may be individually configured to provide the optimum execution environment for 
  12375. the application which will run within it. 
  12376.  
  12377. DOS settings may be set by the user when adding an application to a group on 
  12378. the desktop, or in certain cases, during execution while an application is 
  12379. running within the virtual DOS machine.  In the case where a VDM is created by 
  12380. another process using a DosStartSession() function call, a buffer may be 
  12381. provided containing the required DOS settings and their values. 
  12382.  
  12383.  
  12384. ΓòÉΓòÉΓòÉ 22. Virtual Machine Boot ΓòÉΓòÉΓòÉ
  12385.  
  12386. An important goal of OS/2 Version 2.0 is the ability to run past, current, and 
  12387. future DOS programs; indeed most DOS applications available today run unchanged 
  12388. in the MVDM environment. 
  12389.  
  12390. However, it should be remembered that the "DOS" which runs in this case is 
  12391. highly optimized for (and specific to) an OS/2 Version 2.0 virtual 8086 
  12392. machine. Because of this, there are fundamental internal differences between 
  12393. the DOS Emulation provided under OS/2 Version 2.0 and "real" DOS. Two problems 
  12394. may therefore arise: 
  12395.  
  12396.  1. Some programs may depend on specific DOS features such as internal control 
  12397.     blocks, LAN Redirector hooks, or even undocumented functions, which are not 
  12398.     present in MVDM's DOS Emulation. 
  12399.  2. Only DOS character device drivers can be loaded in MVDM's DOS Emulation. 
  12400.     The user may own a block device (such as a special disk or tape drive) for 
  12401.     which no OS/2 driver is available. (A block device is one accessed via a 
  12402.     drive letter, such as E:). 
  12403.  
  12404. Virtual Machine Boot (VMB) solves both these problems. It allows the user to 
  12405. boot "off-the-shelf" DOS and use block device drivers in an OS/2 Version 2.0 
  12406. virtual DOS machine, ensuring greater compatibility for DOS applications. 
  12407.  
  12408. Another possible use of VMB is to run DOS of a different National Language to 
  12409. that of OS/2 Version 2.0 itself. This may be useful in a multilingual 
  12410. environment. 
  12411.  
  12412.  
  12413. ΓòÉΓòÉΓòÉ 22.1. VMB Environment ΓòÉΓòÉΓòÉ
  12414.  
  12415. The 80386 processor and VDM component of OS/2 Version 2.0 together emulate a 
  12416. 8086 processor, keyboard, display, BIOS and other supporting hardware;  in 
  12417. effect, a complete "virtual Personal Computer".  It is therefore possible for 
  12418. "real" DOS to be loaded in a VDM  session.  Control is passed to the boot 
  12419. record (the first sector) of the DOS system diskette, which in turn loads and 
  12420. initializes the rest of the DOS kernel, just as it does when booting on a 
  12421. physical PC. 
  12422.  
  12423. Indeed, the VDM environment is so similar to a real PC environment that VMB can 
  12424. actually support any 8086 operating system kernel, such as Digital Research's 
  12425. DR-DOS** and CP/M**, Microsoft MS-DOS**, or even a PS/2 reference diskette (but 
  12426. do not attempt to run diagnostics or change the configuration from a VDM; the 
  12427. results are unpredictable). However, since the purpose of VMB is to run current 
  12428. DOS applications, formal IBM support is announced for IBM PC DOS 3.x, 4.0, and 
  12429. 5.0 only. 
  12430.  
  12431. Table "Free Base Memory" shows the amount of available base memory for MVDM DOS 
  12432. Emulation, DOS in a VMB session, and native DOS.  These figures show the amount 
  12433. of memory available after loading the operating system and mouse, EMS and XMS 
  12434. support. 
  12435.  
  12436. A VDM using VMB is similar in function to any other virtual DOS machine. 
  12437. Multiple VDMs may be started and operated concurrently using Virtual Machine 
  12438. Boot.  Each runs in its own virtual 8086 machine; access to hardware and other 
  12439. system resources is managed by MVDM and the underlying OS/2 Version 2.0 
  12440. operating system. 
  12441.  
  12442.  
  12443. ΓòÉΓòÉΓòÉ 22.2. Configuring Virtual Machine Boot ΓòÉΓòÉΓòÉ
  12444.  
  12445. The DOS operating system loaded into a VDM by VMB  may be: 
  12446.  
  12447.  1. An actual DOS system diskette 
  12448.  2. An image of a DOS system diskette saved to hard disk 
  12449.  3. A DOS partition on hard disk. 
  12450.  
  12451. For any of the alternatives, we need to do the following: 
  12452.  
  12453.  1. Set up the start-up batch file AUTOEXEC.BAT 
  12454.  
  12455.  2. Set up the configuration file CONFIG.SYS 
  12456.  
  12457.  3. Provide OS/2 V2.0 with the real DOS to boot. 
  12458.  
  12459.  
  12460. ΓòÉΓòÉΓòÉ 22.2.1. Preparing AUTOEXEC.BAT and CONFIG.SYS ΓòÉΓòÉΓòÉ
  12461.  
  12462. The AUTOEXEC.BAT and CONFIG.SYS that will be used by the VMB at initialization 
  12463. are not the ones found in the root directory of the OS/2 V2.0 boot drive. Table 
  12464. "Location of AUTOEXEC.BAT and CONFIG.SYS" explains which AUTOEXEC.BAT and 
  12465. CONFIG.SYS will be used for the different DOS session types under OS/2 V2.0. 
  12466.  
  12467. CONFIG.SYS requires special attention for the following reasons: 
  12468.  
  12469.  1. Write access to the hard disk is denied the Virtual Machine Boot session to 
  12470.     preserve system integrity, since the real DOS is unaware of OS/2 V2.0 and 
  12471.     the other applications running. 
  12472.  
  12473.     The OS/2 device driver FSFILTER.SYS is provided to address the above 
  12474.     problem. 
  12475.  
  12476.  2. HPFS partitions are not visible to the real DOS running. 
  12477.  
  12478.     FSFILTER.SYS allows the DOS in the Virtual Machine Boot to access HPFS 
  12479.     files. 
  12480.  
  12481.  3. OS/2 V2.0 provides its own mouse, EMS and XMS to each virtual DOS machine, 
  12482.     so there is no need to load the equivalent drivers available for native 
  12483.     DOS. Those provided with the real DOS should not be used. 
  12484.  
  12485.     However, some DOS programs test for the presence of these drivers. OS/2 
  12486.     V2.0 provides the equivalent "stub" drivers to satisfy these programs that 
  12487.     the services actually are available. 
  12488.  
  12489.     The following types of device drivers should also be omitted from 
  12490.     CONFIG.SYS: 
  12491.  
  12492.     Disk cache 
  12493.     Print spooler 
  12494.     RAM disk 
  12495.  
  12496.     These facilities are already provided by OS/2 Version 2.0 and may be 
  12497.     accessed by virtual DOS machines and VMB sessions; including them with DOS 
  12498.     leads to unnecessary duplication, and may impact overall performance. 
  12499.  
  12500. When the Virtual Machine Boot is started from a diskette image on the hard 
  12501. disk, the real DOS sees the diskette image as drive A:. The real drive A: 
  12502. cannot be accessed. OS/2 V2.0 provides a DOS program, FSACCESS.EXE, that can be 
  12503. used from the DOS command prompt or inserted in AUTOEXEC.BAT to overcome this 
  12504. problem. 
  12505.  
  12506. We will cover each of these special requirements in detail in the following 
  12507. sections. 
  12508.  
  12509. Drive Letter Allocation and Access 
  12510.  
  12511. Drive letter allocation and access is one of the more complex areas of VMB, 
  12512. mainly due to the automatic drive letter allocation performed by DOS, and the 
  12513. limitations of earlier DOS versions. The following possible areas of confusion 
  12514. may arise for the user: 
  12515.  
  12516.  If DOS is booted from an image file, it sees this image file as its A: drive. 
  12517.   This prevents access to the real A:  diskette drive. Attempts to write to the 
  12518.   apparent A: drive will fail. 
  12519.  
  12520.  Unlike the DOS Emulation kernel provided by OS/2 Version 2.0, the "real" DOS 
  12521.   booted by VMB cannot see or access an HPFS partition on the hard disk. 
  12522.  
  12523.  A DOS 3.x VDM cannot see a large (>32MB) FAT partition on the fixed disk, or 
  12524.   FAT partitions beyond an HPFS partition on the disk. 
  12525.  
  12526.  Even if the booted DOS can otherwise see the hard disk partition, it is only 
  12527.   given read access. Attempts to write will fail with simulated errors such as 
  12528.   General failure writing drive C:". The user might mistake this for a genuine 
  12529.   hardware fault. 
  12530.  
  12531.  If the booted DOS loads a block device-driver, the allocated drive letter may 
  12532.   be the same as that of a different device outside this VDM, thereby 
  12533.   preventing access to that device from within the VDM. 
  12534.  
  12535. The results could be somewhat disorienting for the user. To help resolve these 
  12536. issues, two utilities FSFILTER and FSACCESS are provided with OS/2 Version 2.0. 
  12537.  
  12538. It is recommended that disk volumes should always be given a meaningful name, 
  12539. either when formatting or later using the LABEL command. This name will remain 
  12540. constant regardless of drive letter allocation, and will aid in identifying a 
  12541. particular volume, even if the assigned drive letter is different. FSFILTER 
  12542.  
  12543. FSFILTER.SYS is a device driver which manages DOS VDM access to OS/2 disks. 
  12544. FSFILTER.SYS should be copied from the \OS2\MDOS directory to the DOS diskette, 
  12545. and the following statement added to the CONFIG.SYS file of the bootable DOS 
  12546. diskette or image. 
  12547.  
  12548. device=a:fsfilter.sys
  12549.  
  12550. This statement should precede any DEVICE= statements which load block device 
  12551. drivers. 
  12552.  
  12553. Note that FSFILTER.SYS gives DOS full access to all OS/2 partitions, regardless 
  12554. of their file system type or partition size. 
  12555.  
  12556. This is an important and somewhat surprising point. For example, DOS 3.3 (in a 
  12557. VDM) has no problem accessing a 300MB HPFS partition, once FSFILTER is loaded. 
  12558. I/O calls within the DOS virtual machine are passed transparently to OS/2 
  12559. Version 2.0. DOS itself is unaware of the underlying file system. DOS can read, 
  12560. write and modify files on the hard disk, and for most configurations the drive 
  12561. letter mapping within the VMB session will match those of OS/2 Version 2.0. 
  12562.  
  12563. The FSFILTER device driver occupies approximately 11KB of memory.  It can be 
  12564. loaded into high memory under DOS 5.0 by specifying the command DEVICEHIGH = 
  12565. FSFILTER.SYS in CONFIG.SYS. 
  12566.  
  12567. The users should also specify the path to COMMAND.COM in the SHELL= statement 
  12568. of CONFIG.SYS.  For example, if DOS files have been copied to C:\DOS, the 
  12569. CONFIG.SYS file on a diskette intended for VMB should contain the following 
  12570. statement: 
  12571.  
  12572. SHELL=c:\DOS\COMMAND.COM c:\dos /p
  12573.  
  12574. The first parameter specifies the command processor to be loaded. The second 
  12575. parameter specifies the reload path (that is, the COMSPEC path). This is 
  12576. preferable to a SET COMSPEC = command in AUTOEXEC.BAT. 
  12577.  
  12578. Each block device driver loaded in DOS CONFIG.SYS is allocated the next free 
  12579. OS/2 letter excluding LAN drives.  This can result in a drive letter clash.  An 
  12580. example may illustrate the point. OS/2 drives are: 
  12581.  
  12582. A:   Diskette drive 0 
  12583. B:   Diskette drive 1 
  12584. C:   Hard disk 
  12585. D:   External diskette drive 
  12586. E:   Remote LAN drive on a server 
  12587.  
  12588. FSFILTER will ensure that a booted DOS sees these drives by the same letter. 
  12589. The booted DOS has the same access to the external diskette drive and LAN 
  12590. resources as does OS/2 itself. This is true whether the VMB session is started 
  12591. before or after user logon to the network, when remote drive letters are 
  12592. assigned. 
  12593.  
  12594. However, a block device driver in a VMB session will also initialize as E:, so 
  12595. LAN drive access is lost. To remedy this, issue an "fsaccess f=e" command. The 
  12596. LAN drive is now accessible as F:  within the DOS session. 
  12597.  
  12598. Note that even when FSFILTER is loaded, the following restrictions still apply: 
  12599.  
  12600.  A VMB session cannot see HPFS files or directories which have: 
  12601.  
  12602.    - Long file names (9 or more characters) 
  12603.    - Invalid FAT characters (for example, plus, comma, blank) 
  12604.    - Multiple dot separators. 
  12605.  
  12606.  HPFS file names containing lowercase letters are folded to uppercase. 
  12607.  
  12608.  PC DOS commands which require low-level disk access will fail.  These 
  12609.   include: 
  12610.  
  12611.    - CHKDSK 
  12612.    - SYS 
  12613.    - UNDELETE 
  12614.    - FORMAT 
  12615.    - UNFORMAT 
  12616.    - MIRROR. 
  12617.  
  12618.   In such cases OS/2 Version 2.0 will simulate a disk error condition. DOS may 
  12619.   interpret this as a hardware fault, or report that the command is not 
  12620.   supported on a network or assigned drive. 
  12621.  
  12622. FSACCESS 
  12623.  
  12624. FSACCESS.EXE is a utility supplied with OS/2 Version 2.0 but intended to run in 
  12625. a VMB session. It cooperates with FSFILTER to manage drive letters within the 
  12626. VMB session. This serves three purposes: 
  12627.  
  12628.  1. Drives may be registered for filtering. 
  12629.  
  12630.  2. The drive letter for a device can be changed, giving consistency across 
  12631.     sessions. 
  12632.  
  12633.  3. Letters can be removed in order to hide the OS/2 device from the VMB 
  12634.     session. 
  12635.  
  12636. The syntax of the FSACCESS command is: 
  12637.  
  12638. FSACCESS ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
  12639.                          Γö£ΓöÇΓö¼ΓöÇΓöÇΓöÇΓö¼ΓöÇ DOSletter ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ     Γöé
  12640.                          Γöé Γöö ! Γöÿ                         Γöé
  12641.                          Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ DOSletter - DOSletter ΓöÇΓöÇΓöñ
  12642.                          Γöé                               Γöé
  12643.                          ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ DOSletter = OS2drive  ΓöÇΓöÇΓöÿ
  12644.  
  12645. FSACCESS            Lists the current drive mapping. For example: 
  12646.  
  12647.                                                      Local C: is mapped to OS/2 C:
  12648.                                                      Local D: is mapped to OS/2 D:
  12649.                                                      Local E: is mapped to OS/2 K:
  12650.  
  12651. FSACCESS F:         Registers DOS letter F: for filtering. References to F: 
  12652.                     will be sent to OS/2 Version 2.0. 
  12653.  
  12654. FSACCESS !F:        De-registers DOS letter F: from filtering. 
  12655.  
  12656. FSACCESS F:-H:      Registers DOS letters F: through H: for filtering. 
  12657.  
  12658. FSACCESS M:=C:      Routes requests for DOS letter M: to OS/2 drive C: 
  12659.  
  12660. Parameters can be combined on a single command line, and the colon is optional. 
  12661.  
  12662. When booting from an image file, it is often desirable to issue the command 
  12663. FSACCESS A: in order to access the A:  diskette drive.  This will remove access 
  12664. to the image file, so the booted DOS will be unable to reload its COMMAND.COM 
  12665. when necessary.  It may be useful to copy all the DOS files to a subdirectory 
  12666. on hard disk, ensuring the PATH and COMSPEC point there. 
  12667.  
  12668. An alternative is to access the diskette drive via a different letter. For 
  12669. example, a user may issue the command FSACCESS G:=A, then use G: to access the 
  12670. real A:  drive.  The image file remains as A:, avoiding PATH and COMSPEC 
  12671. problems. 
  12672.  
  12673.  
  12674. ΓòÉΓòÉΓòÉ 22.2.2. Mouse, EMS and XMS Support ΓòÉΓòÉΓòÉ
  12675.  
  12676. The booted DOS in a VMB session receives XMS (HIMEM), EMS, DPMI and mouse 
  12677. support services from its VDM environment (assuming the virtual DOS machine has 
  12678. default DOS settings).  DOS should not therefore load its own HIMEM, EMS or 
  12679. mouse drivers; indeed they may cause errors in the VDM. 
  12680.  
  12681. DOS programs call these services via appropriate API register parameters and a 
  12682. designated interrupt: 
  12683.  
  12684. Mouse     INT 33h 
  12685. XMS       INT 2Fh (multiplex) 
  12686. EMS       INT 67h 
  12687.  
  12688. These interrupts are trapped by the VDM environment, routed outside the virtual 
  12689. machine and handled by the OS/2 Version 2.0 operating system itself.  This may 
  12690. present a problem for certain programs which first test for the presence of 
  12691. such services by issuing an OPEN command to the associated device driver, or 
  12692. which check that a valid interrupt handler is referenced by the Interrupt 
  12693. Vector Table. When a VMB session is started, these device driver names are not 
  12694. present, and the interrupt vectors point to null handlers. The application will 
  12695. therefore assume that the required services are not useable. 
  12696.  
  12697. In order to avoid this problem, OS/2 Version 2.0 provides three alternative 
  12698. "stub" drivers: 
  12699.  
  12700.  MOUSE.COM 
  12701.  HIMEM.SYS 
  12702.  EMM386.SYS 
  12703.  
  12704. These stub drivers are very small (and use minimal memory when loaded) but 
  12705. satisfy programs which depend on drivers with such names being present. They 
  12706. respond to OPEN commands, and also set handler addresses in the Interrupt 
  12707. Vector Table, thereby satisfying applications which check for the presence of 
  12708. the device drivers in either of these ways. 
  12709.  
  12710. The user must load these OS/2 files rather than any similarly named files which 
  12711. may be shipped with DOS or applications, such as: 
  12712.  
  12713. DOS 4.0   XMAEM.SYS, XMA2EMS.SYS 
  12714.  
  12715. DOS 5.0   HIMEM.SYS, EMM386.EXE, MOUSE.COM 
  12716.  
  12717. DR DOS    HIDOS.SYS, EMM386.SYS, EMMXMA.SYS 
  12718.  
  12719. Other     MOUSE.SYS 
  12720.  
  12721. There are two ways to achieve this. Assuming OS/2 Version 2.0 is installed on 
  12722. drive E: 
  12723.  
  12724.  1. Copy the above OS/2 files from E:\OS2\MDOS to the DOS diskette, and edit 
  12725.     CONFIG.SYS and AUTOEXEC.BAT accordingly to load these files from the A: 
  12726.     drive.  VMDISK may then be run to create a bootable image if desired. 
  12727.  
  12728.            device=a:himem.sys
  12729.            device=a:emm386.sys
  12730.            device=a:fsfilter.sys
  12731.  
  12732.     This method should be used if FSFILTER will be loaded into high memory 
  12733.     using DOS 5.0: 
  12734.  
  12735.            device=a:himem.sys
  12736.            device=a:emm386.sys
  12737.            devicehigh=a:fsfilter.sys
  12738.  
  12739.  2. Edit CONFIG.SYS and AUTOEXEC.BAT to load these files directly from 
  12740.     E:\OS2\MDOS. (FSFILTER.SYS must be loaded first if the OS/2 drive would 
  12741.     otherwise be inaccessible to the booted DOS). 
  12742.  
  12743.            device=a:fsfilter.sys
  12744.            device=e:\os2\mdos\himem.sys
  12745.            device=e:\os2\mdos\emm386.sys
  12746.  
  12747.     The second method has one notable advantage; if and when Corrective Service 
  12748.     is applied to the OS/2 Version 2.0 system, and HIMEM, EMM386 or MOUSE are 
  12749.     updated, it is not necessary to update your DOS diskettes and recreate 
  12750.     image files.  FSFILTER itself will have to be updated manually (unless the 
  12751.     OS/2 Version 2.0 partition is directly accessible to DOS and FSFILTER is 
  12752.     also loaded from here). 
  12753.  
  12754. Note that EMS memory size and frame location are determined by DOS Settings, 
  12755. and not by parameters on the DEVICE= statement for EMM386.SYS. It is 
  12756. recommended that EMS and XMS support should not be configured unless required 
  12757. by the application running in the VMB session, since this can impact overall 
  12758. system performance. 
  12759.  
  12760. We now look at the three different ways to prepare the real DOS to be booted in 
  12761. the VMB. 
  12762.  
  12763.  
  12764. ΓòÉΓòÉΓòÉ 22.2.3. Booting from Diskette ΓòÉΓòÉΓòÉ
  12765.  
  12766. The user may load a specific version of DOS or an equivalent 8086 operating 
  12767. system into a VMB session directly from  a bootable diskette, by specifying A: 
  12768. at the value for DOS_STARTUP_DRIVE under DOS Settings.  Note that this may 
  12769. affect the way in which applications in the VMB session may access the diskette 
  12770. drives;  see Preparing AUTOEXEC.BAT and CONFIG.SYS (Drive Letter Allocation and 
  12771. Access) for further discussion. 
  12772.  
  12773. Here is an example using DOS 5: 
  12774.  
  12775.  1. From a system running DOS 5, format a diskette with the /s option. 
  12776.  
  12777.  2. Copy FSFILTER.SYS from the OS/2 V2.0 subdirectory \OS2\MDOS onto the 
  12778.     diskette. 
  12779.  
  12780.  3. Create CONFIG.SYS and AUTOEXEC.BAT on the diskette. 
  12781.  
  12782.     A sample CONFIG.SYS to use is as follows (OS/2 V2.0 is installed in E: 
  12783.     drive in this example): 
  12784.  
  12785.         REM Load FSFILTER driver
  12786.         DEVICE=A:FSFILTER.SYS
  12787.         REM load the stub XMS and EMS memory drivers from OS2.
  12788.         DEVICE=E:\OS2\MDOS\HIMEM.SYS
  12789.         DEVICE=E:\OS2\MDOS\EMM386.SYS
  12790.  
  12791.     A sample AUTOEXEC.BAT to use is as follows: 
  12792.  
  12793.         @ECHO OFF
  12794.         PROMPT $P$G
  12795.         REM set the path to where the DOS files were copied
  12796.         SET PATH=C:\DOS
  12797.         SET COMSPEC=C:\DOS\COMMAND.COM
  12798.         REM load the stub mouse driver from OS/2 V2.0
  12799.         LH E:\OS2\MDOS\MOUSE
  12800.  
  12801.  4. Create a DOS subdirectory on the hard disk and copy the real DOS files 
  12802.     there. 
  12803.  
  12804.  5. Insert the DOS boot diskette in the A: drive. 
  12805.  
  12806.  6. Locate the Command Prompts folder. It is usually a folder in the OS/2 
  12807.     System icon on the Workplace Shell. 
  12808.  
  12809.  7. Open the Command Prompts  folder. 
  12810.  
  12811.  8. Locate the DOS from drive A: icon and double click on it. 
  12812.  
  12813.     The DOS_STARTUP_DRIVE setting of this icon is pre-set to the value A:. 
  12814.  
  12815. The user cannot specify "B:" or an external diskette drive as the startup 
  12816. drive. There may be situations where it is desired to boot from a 5╨╝ inch 
  12817. diskette; typically the B: drive on PS/2 systems.  One way to do this is by 
  12818. creating an image of the diskette, then booting this image (See Booting from 
  12819. Diskette Image). 
  12820.  
  12821. If a 5╨╝ inch diskette must be booted directly for some reason, this is possible 
  12822. if drive remapping is supported by the system (such as a PS/2 Model 57, 90 or 
  12823. 95). Normally A: is Drive 0 (3╨╗ inch), and B: is Drive 1 (5╨╝ inch, if fitted). 
  12824. To change this, run "Set Startup Sequence" from the reference diskette, and 
  12825. ensure Drive 1 appears before Drive 0. Then the 5╨╝  inch drive will become the 
  12826. A: drive. 
  12827.  
  12828. Some 5╨╝ inch drives (such as the IBM External 1.2MB drive and associated 
  12829. adapter) require a device driver, and are accessed as D: or higher. They cannot 
  12830. be specified as a startup drive, nor can they be readdressed as A:, but can be 
  12831. the source drive when creating a bootable image file. 
  12832.  
  12833.  
  12834. ΓòÉΓòÉΓòÉ 22.2.4. Booting from Diskette Image ΓòÉΓòÉΓòÉ
  12835.  
  12836. A user may also load a specific version of DOS or another 8086 operating system 
  12837. into a VMB session from a diskette image stored on the hard disk. This is 
  12838. achieved by specifying the fully qualified filename of the diskette image file 
  12839. as the value for DOS_STARTUP_DRIVE  under DOS Settings. 
  12840.  
  12841. Here is an example using the DOS 5  boot diskette created in the Booting from 
  12842. Diskette above: 
  12843.  
  12844.  1. Edit CONFIG.SYS on the diskette and add the following statement: 
  12845.  
  12846.         E:\OS2\MDOS\FSACCESS G: = A:
  12847.  
  12848.  2. Create the image of the boot diskette on the hard disk. 
  12849.  
  12850.     Images may be created using the VMDISK utility supplied with OS/2 Version 
  12851.     2.0. The syntax of the VMDISK command is: 
  12852.  
  12853.     vmdisk <source drive> <image filename> 
  12854.  
  12855.     For example: 
  12856.  
  12857.         VMDISK a: c:\bootimg\dos50.vmb
  12858.  
  12859.     The image file is a complete binary "dump" of the diskette, consisting of a 
  12860.     short header record followed by the diskette's boot sector, FAT(s), and all 
  12861.     data clusters.  Its file size corresponds to the size of the source 
  12862.     diskette, regardless of the amount of space actually used on the source 
  12863.     diskette.  No compression of the image is performed. 
  12864.  
  12865.     The diskette must have a standard DOS format (FAT, 512 byte sectors).  It 
  12866.     is not possible to create, then boot, an image of a copy-protected diskette 
  12867.     which has a non-DOS format. It may be possible to boot such a diskette 
  12868.     directly in a VDM. 
  12869.  
  12870.     The VMDISK utility can run under either DOS or OS/2, and supports all 3╨╗ 
  12871.     inch (720KB, 1.44MB and 2.88MB) and 5╨╝ inch (360KB and 1.2MB) source 
  12872.     diskette formats. 
  12873.  
  12874.     Note that VMDISK works one way only; it is not possible to create a 
  12875.     diskette from a VMDISK image. 
  12876.  
  12877.  3. Proceed to add an icon to the OS/2 V2.0 Workplace Shell to launch VMB. 
  12878.     Refer to Putting the Virtual Machine Boot Session in the Workplace Shell on 
  12879.     customizing the Virtual Machine Boot, in particular the DOS_STARTUP_DRIVE 
  12880.     setting. 
  12881.  
  12882.  
  12883. ΓòÉΓòÉΓòÉ 22.2.5. Booting from a DOS Partition ΓòÉΓòÉΓòÉ
  12884.  
  12885. If VMB will be used regularly, the most convenient method may be to do so from 
  12886. a DOS partition on hard disk, rather than via diskettes or diskette images. 
  12887. This may be achieved by specifying C: as the value for DOS_STARTUP_DRIVE under 
  12888. DOS Settings. Loading DOS from a DOS partition proceeds more quickly and offers 
  12889. the user a more "familiar" working environment. It is also easier to apply DOS 
  12890. Corrective Service to a disk partition than to diskettes or images. 
  12891.  
  12892. Note that this method is different from that of a single hard disk partition 
  12893. with the Dual Boot feature available under previous versions of OS/2. 
  12894.  
  12895. In order to load DOS from a DOS partition, the following requirements must be 
  12896. satisfied: 
  12897.  
  12898.  1. Boot Manager must be installed 
  12899.  
  12900.  2. DOS must be installed on a primary partition on the first hard disk in the 
  12901.     machine 
  12902.  
  12903.  3. OS/2 Version 2.0 must be installed on an extended partition on the first 
  12904.     fixed disk, or on another hard disk. 
  12905.  
  12906. This will require re-partitioning on single-drive systems if the disk initially 
  12907. contains DOS alone, or earlier versions of OS/2. 
  12908.  
  12909. Loading DOS from a DOS partition presents one significant problem.  The DOS 
  12910. partition is itself bootable directly via Boot Manager, should the user so 
  12911. choose, and there may a requirement to boot this DOS partition directly on 
  12912. occasions.  OS/2 Version 2.0 provides stub device drivers for functions such as 
  12913. EMS, XMS and mouse support in the VMB session, and these must be used in place 
  12914. of the normal DOS device drivers when DOS is booted in a VMB session. Since the 
  12915. same CONFIG.SYS  and AUTOEXEC.BAT in the C: root directory is used, the 
  12916. question arises of which drivers should be specified for functions such as EMS 
  12917. and XMS support: 
  12918.  
  12919.  If the partition is booted via VMB, the DOS drivers are inappropriate 
  12920.  
  12921.  If the partition is booted directly via Boot Manager, the OS/2 stub drivers 
  12922.   are inappropriate. 
  12923.  
  12924. It might appear that the user would have to maintain multiple configuration 
  12925. files and rename or copy them depending upon whether the partition was being 
  12926. booted into a VMB session or directly from Boot Manager.  This is clearly 
  12927. unsatisfactory. Fortunately there is a solution which avoids this. The key is 
  12928. to specify both sets of drivers, in the correct order, in CONFIG.SYS and 
  12929. AUTOEXEC.BAT. 
  12930.  
  12931. The following example assumes: 
  12932.  
  12933.  DOS 5.0 is installed on the C: Primary partition 
  12934.  OS/2 Version 2.0 is installed on the E: Extended partition 
  12935.  
  12936. CONFIG.SYS on the C: drive contains: 
  12937.  
  12938. device=c:\dos\setver.exe
  12939. device=c:\dos\himem.sys
  12940. device=c:\dos\emm386.exe noems
  12941. device=e:\os2\mdos\himem.sys
  12942. device=e:\os2\mdos\emm386.sys
  12943. dos=high,umb
  12944.    ... etc ...
  12945.  
  12946. When this file is processed in an OS/2 VMB session, the DOS HIMEM load fails as 
  12947. it sees no available extended memory. EMM386.EXE cannot load as it sees 
  12948. protect-mode software already running. Then, the OS/2 HIMEM and EMM386 stub 
  12949. device drivers load as normal. 
  12950.  
  12951. When this file is processed as part of a native DOS boot, the DOS HIMEM and 
  12952. EMM386 load as normal, but the OS/2 stub device drivers detect that they are 
  12953. not running under OS/2 and do not load themselves. 
  12954.  
  12955. A similar technique works for mouse support in AUTOEXEC.BAT: 
  12956.  
  12957. @echo off
  12958. prompt $p$g
  12959. set path=c:\dos
  12960. LH e:\os2\mdos\mouse
  12961. LH c:\dos\mouse
  12962.    ... etc ...
  12963.  
  12964. Note that here the OS/2 driver is listed first. When this file is processed in 
  12965. an OS/2 VMB session, the OS/2 stub loads first.  The DOS mouse driver sees that 
  12966. a mouse driver is already present, and hence it does not install itself.  When 
  12967. booting DOS natively, the OS/2 mouse stub device driver detects that it is not 
  12968. running under OS/2, and does not load itself. The DOS mouse driver then loads 
  12969. as normal. 
  12970.  
  12971.  
  12972. ΓòÉΓòÉΓòÉ 22.2.6. Putting the Virtual Machine Boot Session in the Workplace Shell ΓòÉΓòÉΓòÉ
  12973.  
  12974. We are now ready to put the VMB session as an object on the OS/2 Version 2.0 
  12975. Workplace Shell desktop. 
  12976.  
  12977.  1. Locate the Templates folder. It is usually an icon on the Workplace Shell. 
  12978.  
  12979.  2. Open the Templates folder. 
  12980.  
  12981.  3. Locate the Program icon template. 
  12982.  
  12983.  4. Drag the Program icon template on to the desktop. This will cause the 
  12984.     Program Settings notebook to appear. 
  12985.  
  12986.  5. Enter an asterisk "*" in the Path and file name field. 
  12987.  
  12988.     See the example as shown in Figure "The Program Page of the Settings 
  12989.     Notebook for a VMB". 
  12990.  
  12991.  6. Select the Session notebook tab. 
  12992.  
  12993.     The Session notebook allows the user to specify the session type and DOS 
  12994.     Settings  for the VMB session. 
  12995.  
  12996.  7. Select either DOS full screen or DOS window and then select the DOS 
  12997.     Settings... button. 
  12998.  
  12999.  8. Select the DOS_STARTUP_DRIVE list item. 
  13000.  
  13001.     The difference between a VMB session and a "normal" VDM is that the DOS 
  13002.     Settings value of DOS_STARTUP_DRIVE is set. This setting determines the 
  13003.     location of the DOS kernel to be booted.  By default, MVDM's DOS Emulation 
  13004.     is loaded.  However, the user may specify a location from which to load 
  13005.     DOS, in which case the version of DOS residing at that location is loaded. 
  13006.  
  13007.     Figure "DOS Settings - DOS_STARTUP_DRIVE" 
  13008.  
  13009.     Example values for DOS startup drive are: 
  13010.  
  13011.    DOS Start up setting          Meaning 
  13012.    a:                            Boot using the diskette in drive A: 
  13013.    c:\bootimg\dos50.vmb          Boot using the specified DOS image file 
  13014.    c:                            Boot using the primary partition of the C: 
  13015.                                  drive 
  13016.  
  13017.     The following restrictions apply: 
  13018.  
  13019.     A second diskette drive (B:) or hard disk (D:) cannot be specified as the 
  13020.      startup drive. 
  13021.  
  13022.     To boot DOS from the C: partition, Boot Manager must be installed, and 
  13023.      OS/2 Version 2.0 must reside in an extended partition on the first hard 
  13024.      disk, or on another hard disk. See Booting from a DOS Partition. 
  13025.  
  13026.  9. Select the Save button to save the DOS settings and return. 
  13027.  
  13028. 10. Select the General notebook tab. 
  13029.  
  13030. 11. Change the Title field to your own name describing the new object. 
  13031.  
  13032. 12. Close the Settings notebook by double clicking on the system menu in the 
  13033.     upper left corner of the window. 
  13034.  
  13035. Other DOS Settings 
  13036.  
  13037. DOS settings which control the VDM hardware environment are applicable to the 
  13038. VMB session and operate in the same way as for a DOS Emulation windowed or 
  13039. full-screen session. Those which modify the virtual DOS environment are 
  13040. ignored; the equivalent settings are instead determined by the CONFIG.SYS file 
  13041. of the booted DOS kernel. Ignored settings include: 
  13042.  
  13043.  DOS_BREAK 
  13044.  DOS_DEVICES 
  13045.  DOS_UMB 
  13046.  DOS_SHELL 
  13047.  DOS_HIGH 
  13048.  DOS_LASTDRIVE 
  13049.  DOS_VERSION 
  13050.  
  13051. The FCB limit is the lesser of either the booted DOS, or OS/2 Version 2.0 
  13052. CONFIG.SYS value.  The VMB session will by default have 640KB of real memory, 
  13053. mou se support, 2MB Expanded (EMS) memory, 2MB DPMI, and 2MB XMS memory. 
  13054.  
  13055. Booting from an OS/2 V2.0 Program 
  13056.  
  13057. By using DosStartSession it is possible to start a VMB session from an OS/2 
  13058. V2.0 program. For more details see the following sample which shows how to boot 
  13059. from the disk drive A:. Of course, by changing startd.Environment, this sample 
  13060. can also be used to start a VMB from another hard disk partition or a boot 
  13061. image file from your hard disk. 
  13062.  
  13063. Figure "VMB from an OS/2 2.0 Program" 
  13064.  
  13065.  
  13066. ΓòÉΓòÉΓòÉ 22.3. Managing the VMB Session ΓòÉΓòÉΓòÉ
  13067.  
  13068. The user may interact with a VMB session in a similar way to any other virtual 
  13069. DOS machine.  The session may be scaled, minimized, maximized and switched 
  13070. between windowed and full-screen mode, and is subject to the same graphics mode 
  13071. limitations when windowed. However, a VMB session cannot be ended by typing 
  13072. EXIT at its command prompt. The session can only be closed from its system icon 
  13073. or the Window List. 
  13074.  
  13075. Note that Ctrl-Alt-Del will reboot the entire OS/2 Version 2.0 operating 
  13076. system, not just the foreground virtual machine session. 
  13077.  
  13078.  
  13079. ΓòÉΓòÉΓòÉ 22.4. VMB Limitations ΓòÉΓòÉΓòÉ
  13080.  
  13081. VMB does not support: 
  13082.  
  13083.  VCPI and other non-DPMI DOS extenders 
  13084.  I/O to disk which bypasses the file system 
  13085.  Feature adapter sharing without a virtual device driver 
  13086.  Real-time or timing-critical DOS applications 
  13087.  Some copy-protection schemes. 
  13088.  
  13089. These limitations arise in the most part from the limitations of the MVDM 
  13090. environment, which are imposed in order to protect overall system integrity. 
  13091.  
  13092.  
  13093. ΓòÉΓòÉΓòÉ 22.5. Summary ΓòÉΓòÉΓòÉ
  13094.  
  13095. The DOS Emulation kernel which is normally used to support the execution of DOS 
  13096. applications in a VDM is exactly what its name implies; an emulation of the DOS 
  13097. operating system and associated services.  While this suffices for most DOS 
  13098. applications, certain applications exist which take advantage of unique and/or 
  13099. undocumented features which exist only in specific versions of DOS. 
  13100.  
  13101. To allow such applications to be successfully run under OS/2 Version 2.0, the 
  13102. VMB (Virtual Machine Boot) feature is provided.  This feature allows a "real" 
  13103. DOS operating system, or indeed most other 8086 operating systems, to be booted 
  13104. in a virtual DOS machine.  The operating system may be booted from either a 
  13105. diskette in drive A:, a diskette image on a hard disk, or a partition on a hard 
  13106. disk. 
  13107.  
  13108. Applications which run using Virtual Machine Boot may take advantage of the 
  13109. EMS, XMS and mouse support provided to virtual DOS machines by OS/2 Version 
  13110. 2.0.  This support is provided through stub device drivers supplied with OS/2 
  13111. Version 2.0; these should be used in preference to the device drivers supplied 
  13112. with the operating system or applications. 
  13113.  
  13114.  
  13115. ΓòÉΓòÉΓòÉ 23. Running Personal Communications/3270 Version 2 for Windows ΓòÉΓòÉΓòÉ
  13116.  
  13117. Personal Communications 3270 Version 2 for Windows offers a high-function 3270 
  13118. emulator for the Windows environment. It supports a variety of host 
  13119. connections, including DFT, LAN via IEEE 802.2 protocol, LAN via NETBIOS and 
  13120. SDLC. It is possible to run this 3270 emulator in an OS/2 V2.0 "seamless" 
  13121. WIN-OS/2 VDM. 
  13122.  
  13123. Figure "Personal Communications/3270 for Windows running under OS/2 V2.0" 
  13124.  
  13125. We will describe below the procedure for installing and running Personal 
  13126. Communications/3270 for Windows for a host connection via a LAN using the IEEE 
  13127. 802.2 protocol. We will also describe how to install any Corrective Service 
  13128. Diskettes for this emulator package. 
  13129.  
  13130.  
  13131. ΓòÉΓòÉΓòÉ 23.1. Installing PC/3270 under WIN-OS/2 ΓòÉΓòÉΓòÉ
  13132.  
  13133. You must have installed OS/2 Version 2.0, including the WIN-OS/2 support in 
  13134. order for this to work. 
  13135.  
  13136.  1. From the OS/2 Desktop: 
  13137.  
  13138.     Open the OS/2 System Folder 
  13139.     Open the Command Prompts Folder 
  13140.     Select WIN-OS/2 full-screen 
  13141.  
  13142.     This will start up the WIN-OS/2 environment. You will get the WIN-OS/2 
  13143.     Program Manager screen, just as you would if you had started Windows 
  13144.     natively. From here the installation of the product and the corrective 
  13145.     service is just as it would be under Windows. 
  13146.  
  13147.  2. From the Program Manager Menu Bar: 
  13148.  
  13149.     Select File 
  13150.     Select Run 
  13151.     Insert PC/3270 Windows Diskette 1 in the A: drive 
  13152.     On the command line enter: A:INSTALL 
  13153.  
  13154.     Now you will fill out the installation and configuration screens just as 
  13155.     you would have installing PC/3270 directly under Windows. 
  13156.  
  13157.     In this sample installation we will use the following throughout this part 
  13158.     of the document: 
  13159.  
  13160.            C:           is the drive where OS/2 Version 2.0 is installed
  13161.            C:\PC3270W   is the drive and subdirectory where PC/3270 is installed
  13162.            PC3270W      is the name of the configuration file we create
  13163.  
  13164.  3. Select OK on the PC/3270 Installation logo screen. 
  13165.  
  13166.  4. On the Installation Start screen: 
  13167.  
  13168.     Select Create New Configuration file 
  13169.     Select OK 
  13170.  
  13171.  5. On the Customize Configuration screen: 
  13172.  
  13173.     Select Connection type. 
  13174.  
  13175.      Our sample will use DFT, but you can select the one you want. We have 
  13176.      tested DFT, LAN 802.2, SDLC and IIN Async at 9600bps. 
  13177.  
  13178.      If you select other than DFT, you will need to configure your 
  13179.      communications parameters before you can continue. You will need to refer 
  13180.      to other documentation for this configuration information. 
  13181.     Select 2 for Number of Host sessions. 
  13182.      Yours will probably vary, but start simple. 
  13183.     Select OK. 
  13184.  
  13185.  6. On the Installation End screen: 
  13186.  
  13187.     Enter a Configuration File name of PC3270W 
  13188.     Select Copy Necessary Files only (or if you want: All files) 
  13189.     Enter Drive and Directory of C:\PC3270W\ 
  13190.     Select OK 
  13191.  
  13192.      (These are the defaults) 
  13193.  
  13194.  7. On the Add PC/3720 to Program Manager screen: 
  13195.  
  13196.     Select WIN-OS/2 Main in the to Group section 
  13197.     Select OK 
  13198.  
  13199.     There will be three more pop-up screens with information about the 
  13200.     installation completion, just select OK on each of them to complete the 
  13201.     installation. 
  13202.  
  13203. Note:   If you are configuring 802.2 LAN installations, you will probably get a 
  13204.         PCS121 error at the completion of the install. This is because the 
  13205.         install process is trying to update the CONFIG.SYS file and is having 
  13206.         problems. Just continue with installing the corrective service diskette 
  13207.         in the next section. 
  13208.  
  13209.  
  13210. ΓòÉΓòÉΓòÉ 23.1.1. Installing the Corrective Service Diskettes ΓòÉΓòÉΓòÉ
  13211.  
  13212. Now install the PC/3270 Corrective Service Diskette(s). 
  13213.  
  13214.  1. From the Program Manager Menu Bar: 
  13215.  
  13216.     Select File 
  13217.     Select Run 
  13218.     Insert PC/3270 Corrective Service Diskette in the A: drive 
  13219.     On the command line enter: A:INSTCSD 
  13220.  
  13221.     You will get a pop-up telling you that the CSD will replace files in the 
  13222.     C:\PC3270W\ directory, select OK to continue the update. 
  13223.  
  13224.     When the CSD installation is complete you will get a pop-up telling you 
  13225.     that it is complete, select OK. 
  13226.  
  13227.  2. Close the WIN-OS/2 full-screen session. 
  13228.  
  13229.  3. On the Program Manager menu bar: 
  13230.  
  13231.     Select the Title Bar Icon (upper left corner) 
  13232.     Select Close 
  13233.     Select OK on the Exit WIN-OS/2 pop-up 
  13234.  
  13235. Be sure to read the README.TXT file on the CSD diskette. It will have 
  13236. additional information about the corrective service that might apply to your 
  13237. installation. 
  13238.  
  13239.  
  13240. ΓòÉΓòÉΓòÉ 23.2. Creating a PC/3270 Batch File for OS/2 V2.0 ΓòÉΓòÉΓòÉ
  13241.  
  13242. You now need to check the WIN-OS/2 initialization file and create a batch file 
  13243. for PC/3270. This batch file will be used in the setup of the PC/3270 desktop 
  13244. object later. 
  13245.  
  13246.  
  13247. ΓòÉΓòÉΓòÉ 23.2.1. Checking the WIN-OS/2 Initialization File ΓòÉΓòÉΓòÉ
  13248.  
  13249. The PC/3270 Windows installation should have updated the WIN.INI file. Check 
  13250. the C:\OS2\MDOS\WINOS2\WIN.INI file for the following: 
  13251.  
  13252.  .
  13253.  .
  13254.  .
  13255. [PCS3270]
  13256. DIR=C:\PC3270W\
  13257.  .
  13258.  .
  13259.  .
  13260.  
  13261.  
  13262. ΓòÉΓòÉΓòÉ 23.2.2. Creating the PC/3270-OS/2 Batch File ΓòÉΓòÉΓòÉ
  13263.  
  13264. We will now create a new batch file that can be used to start any of the 
  13265. various PC/3270 configurations. Depending on the communications link you are 
  13266. using, you may need to execute a PC3270W.BAT file to invoke the WIN-OS/2 
  13267. environment. The other types of links invoke WIN-OS/2 directly. This batch file 
  13268. will check for the presence of PC3270W.BAT and use it if it exists. 
  13269.  
  13270. Create the file C:\PC3270W\PC3270WO.BAT 
  13271.  
  13272.    @ECHO OFF
  13273.    IF EXIST PC3270W.BAT GOTO TSR
  13274.    WINOS2.COM PCS3270.EXE
  13275.    GOTO END
  13276.    :TSR
  13277.    PC3270W.BAT PCS3270.EXE
  13278.    :END
  13279.  
  13280.  
  13281. ΓòÉΓòÉΓòÉ 23.2.3. Communications Manager Mouse Support (CMMOUSE) ΓòÉΓòÉΓòÉ
  13282.  
  13283. IBM CM Mouse Support (product 5799-PNJ, RPQ P85221) provides advanced mouse 
  13284. support for Personal Communications/3270 in the Windows environment. CM Mouse 
  13285. must be started in the same VDM (Virtual DOS Machine) as PC/3270. To achieve 
  13286. this, the batch files used to start Windows and PC/3270 must be modified as 
  13287. described in the following sections. 
  13288.  
  13289. When PC/3270 is modified as described below, CM Mouse will automatically be 
  13290. started when you start PC/3270.  CM Mouse may display a "waiting for PC/3270 to 
  13291. start..." message since both CM Mouse and PC/3270 will begin running at the 
  13292. same time.  After PC/3270 starts and the host sessions are established, CM 
  13293. Mouse will automatically continue its initialization (the message "reading BDF 
  13294. files..." will be displayed).  It is suggested that you enable the automatic 
  13295. startup feature of PC/3270 so that the host sessions are established 
  13296. automatically. 
  13297.  
  13298. Installing CM Mouse 
  13299.  
  13300. Install CM Mouse from any OS/2 or DOS command line as described in the CM Mouse 
  13301. documentation.  Note that you must have installed CSD 4002 or later for 
  13302. PC/3270. 
  13303.  
  13304. The following sections assume that you have installed CM Mouse in the default 
  13305. C:\CMMOUSE directory.  If you install CM Mouse in some other directory, change 
  13306. the directory names as necessary. 
  13307.  
  13308. Modifying the PC/3270 OS/2 V2.0 Batch File 
  13309.  
  13310. The batch file created above should be modified as follows (the file is 
  13311. C:\PC3270W\PC3270WO.BAT). The changes from above are shown with this emphasis 
  13312. below: 
  13313.  
  13314.     @ECHO OFF
  13315.     IF EXIST PC3270W.BAT GOTO TSR
  13316.     WINOS2.COM C:\CMMOUSE\CMMOUSE.EXE,C:\PC3270W\PCS3270.EXE
  13317.     GOTO END
  13318.     :TSR
  13319.     PC3270W.BAT C:\PC3270W\PCS3270.EXE
  13320.     :END
  13321.  
  13322. Modifying the PC/3270 Execution Batch File 
  13323.  
  13324. Depending on the configuration of your system, there may or may not be a 
  13325. PC/3270 execution batch file on your system.  If there is, it is named 
  13326. C:\PC3270W\PC3270WX.BAT.  If this file does not exist on your system then skip 
  13327. this section. 
  13328.  
  13329. Modify the line of this batch file which runs the WIN-OS/2 program (the 
  13330. modification is shown with this emphasis): 
  13331.  
  13332.     C:\OS2\MDOS\WINOS2\WIN C:\CMMOUSE\CMMOUSE.EXE,%1 %2 %3 %4 %5 %6 %7 %8 %9
  13333.  
  13334. Note that there must be no blank spaces on either side of the comma character. 
  13335. There may be other commands in this file; do not modify them. 
  13336.  
  13337.  
  13338. ΓòÉΓòÉΓòÉ 23.3. Setting up PC/3270 as a WIN-OS/2 Application ΓòÉΓòÉΓòÉ
  13339.  
  13340. Now we have PC/3270 installed and the batch and configuration files ready to 
  13341. go. The next step is to create an object on the desktop and set the various 
  13342. attributes of that object. 
  13343.  
  13344.  
  13345. ΓòÉΓòÉΓòÉ 23.3.1. Create a New Object on the Desktop ΓòÉΓòÉΓòÉ
  13346.  
  13347. To create an object for PC/3270, from the desktop: 
  13348.  
  13349.  Open the Template Folder 
  13350.  Select the Program folder with the right mouse button 
  13351.  Select Create Another from the pop-up 
  13352.  Select OS/2 Desktop from the list of folders 
  13353.  Select Create on the bottom the window 
  13354.  
  13355. The Program-Settings folder will now open for this new object so you can set 
  13356. the attributes in the next section. 
  13357.  
  13358.  
  13359. ΓòÉΓòÉΓòÉ 23.3.2. Setting the Attributes of the PC/3270 WIN-OS/2 Object ΓòÉΓòÉΓòÉ
  13360.  
  13361. Now we have to set the attributes of this new object so that it will start 
  13362. PC/3270 as a Windows application. 
  13363.  
  13364. The following are common to all types of connections. The LAN 802.2 and 3174 
  13365. Peer connections will require some additional steps covered at the end (they 
  13366. need some unique device drivers). 
  13367.  
  13368. You are now on the Program Settings for this Object. This is where you need to 
  13369. set up all of the various attributes that will go with this object. You move 
  13370. around by selecting the proper tab on this notebook. 
  13371.  
  13372.  1. Select the Program tab (should be selected): 
  13373.  
  13374.     Enter a Path and File name of: C:\PC3270W\PCS3270.EXE 
  13375.     Enter a Working Directory of: C:\PC3270W 
  13376.  
  13377.      The Icon should now show the PC/3270 Icon. If not then the path and/or 
  13378.      file name is entered incorrectly. 
  13379.  
  13380.  2. Select the General tab: 
  13381.  
  13382.     Enter a Title of: PC/3270 for WIN-OS/2 (or something else you want) 
  13383.  
  13384.  3. Select the Window tab: 
  13385.  
  13386.     Select Minimize window to desktop for the Minimized Button Behavior (this 
  13387.      will minimize the PC/3270 Icon on the desktop instead of the minimized 
  13388.      window viewer folder). 
  13389.  
  13390.  4. Select the Session Tab: 
  13391.  
  13392.     Select WIN-OS/2 window. 
  13393.     Select Separate session (this will allow PC/3270 to load required 
  13394.      Terminate-Stay-Resident (TSR) programs even if it is not the first 
  13395.      WIN-OS/2 session started). 
  13396.     Select WIN-OS/2 settings. 
  13397.  
  13398.  5. From the WIN-OS/2 settings screen: 
  13399.  
  13400.     Select and set COM_HOLD=ON (for async only). 
  13401.     Select and set DOS_HIGH=ON (allows DOS to be loaded above 640KB). 
  13402.     Select and set DOS_UMB=ON (allows TSR programs to be loaded in upper 
  13403.      memory blocks). 
  13404.     Select and set IDLE_SENSITIVITY=100 (disables the idle detection so 
  13405.      PC/3270 will get the maximum amount of processor time). 
  13406.     Select and set KBD_ALTHOME_BYPASS=ON (so PA2 will work). 
  13407.     Select and set DOS_SHELL to: 
  13408.  
  13409.             C:\OS2\MDOS\COMMAND.COM C:\OS2\MDOS /P  /C C:\PC3270W\PC3270WO.BAT
  13410.  
  13411.      Note:   This is the batch file we created in the previous step. 
  13412.  
  13413.  
  13414.     Select SAVE when complete. 
  13415.  
  13416.  6. Close the Settings window: 
  13417.  
  13418.     Select the Title Bar Icon (small PC/3270 Icon in upper left hand corner of 
  13419.      Settings screen), or press F10. 
  13420.     Select Close to close and save these object changes. 
  13421.  
  13422.  
  13423. ΓòÉΓòÉΓòÉ 23.4. Additional Setup for LAN Connections ΓòÉΓòÉΓòÉ
  13424.  
  13425. The LAN connections require some additional device drivers in order to 
  13426. communicate with the adapter. 
  13427.  
  13428. Note:   When PC/3270 is using a LAN Adapter, then that adapter cannot be used 
  13429.         by any other program on this workstation. At this time there is no 
  13430.         virtual IEEE 802.2 device driver available to allow adapter sharing, 
  13431.         which means that PC/3270 will have exclusive use of this adapter when 
  13432.         it is running. 
  13433.  
  13434. We will set up PC/3270 to use a Token-Ring adapter. You could set it up to use 
  13435. Ethernet, PC Network or 3174 Peer (LAN over Coax) using the same technique. 
  13436.  
  13437.  
  13438. ΓòÉΓòÉΓòÉ 23.4.1. Installing LAN Support Program and RESETOKN.SYS ΓòÉΓòÉΓòÉ
  13439.  
  13440. You must install the PC LAN Support program so that you will have the proper 
  13441. device drivers. You should use the COPY command to copy the device drivers from 
  13442. the LSP 1.2x diskette in drive A:. 
  13443.  
  13444.    MD C:\LSP
  13445.    COPY A:\DXMA0MOD.SYS C:\LSP
  13446.    COPY A:\DXMC0MOD.SYS C:\LSP
  13447.  
  13448. Additionally you should get the RESETOKN.SYS device driver and copy it into the 
  13449. C:\LSP directory. 
  13450.  
  13451.    COPY A:\RESETOKN.SYS C:\LSP
  13452.  
  13453. The RESETOKN.SYS device driver will reset the Token-Ring adapter when it is 
  13454. invoked, it is not required, but suggested. This will allow you to stop and 
  13455. restart PC/3270 in a Token-Ring environment. 
  13456.  
  13457. RESETOKN.SYS can be retrieved from: 
  13458.  
  13459.  CompuServe by issuing GO IBMOS2 and downloading RESTKN.ZIP from SECTION 17, 
  13460.   IBMFILES. 
  13461.  IBM National Support Center Bulletin Board System by downloading RESTKN.ZIP. 
  13462.  Internal IBM users can GET the RESTKN PACKAGE from OS2TO